![]() ![]() ![]() |
|
"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman
"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman
stevehodge: I was put back on DLM-1 last night:
The error rate is high, though actually quite a lot better than last time I was on DLM-1 when I was seeing as many as 400 CRC errors per hour. What is interesting is that my sync rate is quite a bit lower than it was last time (48000+), and actually it's lower than it was on DLM-2. The line attenuation is up 1db too, which is a bit odd. I think I will leave it for 8 days to see if DLM makes any changes and then resync manually.
I haven't changed the line settings at all. It'd been on DLM-2 since August 28th. Prior to that it was on DLM-1 since July 24th. Coincidence that these changes seem to be happening about a month apart?
"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman
SamF:
.@sidefx - Yeah, it's hard to say, but I'm going on what the official Chorus docs say on the subject.
"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman
helis:
Wow your line stats are very similar to mine. When you were on DLM2 was kind of CRCPM rate were you seeing?
SamF: @stevehodge - from what I have seen historically, you will need to keep your CRCPM at least under 0.4 and possibly as low as 0.2 (unconfirmed) in order to stay on DLM-1. You might want to look at upping your SNRM a bit to get your errors under control.
stevehodge: To be honest I'm not sure CRC per minute is how DLM is looking at this. One problem I have with CRCPM is that I think the error rate is going to be higher with higher usage (after all you can only have an error if there is data being transmitted). I believe it is more likely that DLM is looking at the number of successfully transmitted bits per CRC error or something similar. That means CRCPM is only half the story - you also need to look at how much data was transmitted.
stevehodge:For me I'm still seeing too many strange things going on with DLM to try to tune for it. For example, why did DLM decide to put me back on DLM-1 now? We believe it makes decisions at least weekly and nothing has changed for me this week versus the last 2 or 3 weeks. Another example is DLM resyncs without changes - why? Or your switch and then switch back a day later - I was DLM-1 for a month with worse error rates than you so why did it downgrade you after only 1 day and yet leave me for a month?.
To be honest I'm not sure CRC per minute is how DLM is looking at this. One problem I have with CRCPM is that I think the error rate is going to be higher with higher usage (after all you can only have an error if there is data being transmitted). I believe it is more likely that DLM is looking at the number of successfully transmitted bits per CRC error or something similar. That means CRCPM is only half the story - you also need to look at how much data was transmitted.
helis:
I thought this too but I have downloaded 10gig in one hit at speeds of 2-3MB/s and had no CRC errors during the 40mins or what ever it was and now I've come back to see I've had 4 CRC errors in the last 15mins. I doubt I've had 50meg of data transfer over the link in the last 15mins.
"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman
|
![]() ![]() ![]() |