Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Chrysalis]

is the new driver just cheating on snrm? I wonder if its deliberately discounting a db or so to gain an extra bit of sync.  Its interesting that capping the speed to the same as the hg612 matches the error rate.

I havent noticed a single issue using my line today, no packet loss, loss of throughput etc. and if DLM didnt exist I would be happy enough, but 6k errors in 30 hours is mouthwatering even for my line.  The ES are way below 2880/day still but still is an eye widening number on CRC.

[les-70]

  All my test always have the same sync speeds for both modems, i am not utilizing the extra attainable in any of the tests. The first speed 72000 gave ~6db with the HG612 but with the 8800NL with 039 shows near 7db.  Even though the 8800NL has the extra SNRM, the ES difference of 10 to 15 occurs then. They only seem to become similar error rates with the speed cap at 64000 such that the HG612 snrm is a bit below ~9.   I was not so worried about that factor of 1.5 in errors as much bigger change in CRC and SES rates.   I noted the CRC and SES values in the 8800NL thread, with a speed such that HG612 is synced close to 6 my 8800NL CRC and SES rates are consistently bigger by x4.

Due to these results I have been fussing over exactly what the DLM might respond to.  If it is just ES it is not so bad but if it is CRC and SES it looks more of an issue.

 Also as you say the connection has always been OK and the real potential problem, if there is one, may be the DLM.

[Chrysalis]

in which case my theory of the less aggressive bitswapping may be playing a part as well then for the error rates.

After some sleep and if I remember will compare bitloading.

Problem is graphs arent working for me at the moment on BE's tool.  I think he doesnt like the idea of slowing the app down more, but on my pc the fast pc setting it still is too fast.