Yes, there still appears to be nightly congestion on the 25/7 service. Last night the max downstream was down from 25 to 17, but services were impacted worse than that indicated; neither TwitchTV nor YouTube could stream without buffering. -- Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org
There is some packetloss. It's hard to measure because it seems to be primarily on large packets. So you could ping something at the default packet size until the cows come home and that doesn't have any problems, but then you run a speed test and can visually see stalls caused by packetloss. While working with wireshark yesterday, I also saw some TCP retransmits despite not being able to spot any packetloss via standard pings. -- Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org
Over the past ten days I've got an average packet loss of about 2%. Sometimes it is fine, sometimes it is pretty bad (bad enough to impact VoIP call quality). I'm on MLPPP in case that matters. Would be nice to get this resolved.
So I guess, (having read through this thread) that this is why my VSDL performance has been slowly getting worse and worse over the last month or so? When I upgraded I was getting 20Mb/s, but the best I get now is 10 on a good day.
I've been seeing such congestion since first day I switched to 25/7 last summer. I just never complained. I have the same configuration as Phibian (double 25/10 mlppp). It seems to me it's happening to all TekSavvy customers and only at peak hours of the day. So, what Bell/TekSavvy lifted last week is still a question.
It really seems to fluctuate a lot. Sometimes things are fine sometimes not so much. If they are running close to capacity it would likely depend on the particular link that a given customer is on at the time. Some links might be saturated and others not (right?).
I've got smokeping running from my router to the TSI gateway (next hop) as well as a range of other hosts. I've also got the reverse setup (external system with smokeping running) and it sees the TSI gateway just fine (no packet loss) but getting to my IP I get the ~2% loss again. So it looks like the issue is in the Bell link area of things.
Given that I never used to have packet loss issues and others seem to be seeing similar loss I assumed that it was due to capacity issues on the links. My line stats are fine (loads of room to spare). The issues also come and go with the time of day (again suggesting capacity issue rather than line problems). Does it make any difference if I'm running in MLPPP mode versus someone who's not (I think I saw that you're not these days)? I vaguely remember reading something about all MLPPP connections being routed over one link? That doesn't sound right to me but I'm not an expert in that area.
My thinking is that TSI is purposefully running (too) close to capacity and waiting for the CRTC descision to come down before ordering more links. While I can understand that they are between a rock and a hard place I also don't like having my VoIP go choppy on me due to packet loss.
For my MLPPP I'm using two separate phone lines (two modems) bonded by a Cisco router. All equipment is directly connected to the demarc point in my basement with short cords. Here is my ping from the Cisco router to the next hop which is a TekSavvy gateway:
router#ping 126.96.36.199 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!.! Success rate is 98 percent (98/100), round-trip min/avg/max = 20/26/144 ms router#
As you can see there is 2% packets loss as well. Again, it happens only between ~7PM and 12AM every day.
I don't really know how to fight all these ISPs to provide high quality service to their customers. I would suggest mister TSI Marc & company to apply more power into solving lots of technical problems like this congestion, broken CS with extremely long hold time etc. instead of focusing teenagers' attention on BS like Copyrights.