Drastic improvements during international outages

[anakin]

Every single time there's an international outage, there are drastic improvements in speeds and latency with MyWi, even to Brixton. This remains even when international services have been partially restored, like now.

What could one deduce from this? Are MyWi problems caused by:

- international P2P?
- all MyWi downloads their MS updates internationally?
- MyWi hosts sites internationally?
- what else?

--- My views are mine, and mine alone. ---

 

[loosecannon]

people give up on the internet when there is a loss of there fav service and certainaly P2P clients timeout so that frees up BW

this cant be used as a excuse/justification as the users giving up are probably also frustrated and angry ... that small percentage of disgrunteled users is growing sentech ...

 

[Headend]

Here a new way to test the international link. If your average ping time to sentech is less than 100ms, all is not well...

Ping statistics for 66.18.65.115:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 62ms, Maximum = 141ms, Average = 90ms

Headend
Tower: Mintek (82 was 12) - Signal: 19% - Firmware: 4.2.1.8 - 128k - Smoothwall and PPPoE

 

[anakin]

International has just been fully restored moments ago. Speeds go from around 13KB/s to around 6KB/s, packet loss from 0% to 3%. I wouldn't have thought international usage would have such an effect on MyWi.

--- My views are mine, and mine alone. ---

 

[guest2013-1]

Okay, you guys obviously don't read what TheRodent had to say about this....

Basically, what they're doing is to drop the packets you request from the international link as a measure to limit you to a speed, this makes you request them again, which in turns goes through the tower/international link again.

The number gets SO great, that a this causes a bottleneck, not only through their link, but between their towers as well, because not only does each tower need to keep requesting packets they drop, they need to service you with that data collected.

Like TheRodent said, they should rather buffer whatever data gets downloaded instead of dropping the packets and limit you in this way, doing that would free up alot of round tripping etc

Hope that made sense, and this is what i understand of what is going wrong (or one of the theories why) so i might be wrong in some instances

Help save the bandwidth. Decent download speeds for TheRodent! Stop downloading now!!!

 

[qdada]

I use eMule a lot and something has always bugged me...

I have set the queue limit to 2000 clients, what I want to know is how much bandwidth does one use keeping all those emule clients on que ? Surely one uses bandwith to keep those clients on the queue ?

Oddly though ... I disconnect and close emule alltogether and do a 'netstat -a'I find a very long list of ip addresses waiting to connect to eMule port. So even after one closes eMule it would appear one is still using bandwidth ?

 

[Turtle]

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by qDot</i>
<br />
Oddly though ... I disconnect and close emule alltogether and do a 'netstat -a'I find a very long list of ip addresses waiting to connect to eMule port. So even after one closes eMule it would appear one is still using bandwidth ?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
What does the 'state' column say about those connections? If they are FIN_WAIT or TIME_WAIT then this is normal .. when a connection is closed, TCP/IP normally "holds onto" that socket for a minute or two and then closes it (this is a.o. to prevent a new app assigning the same socket potentially before the other end of the previous connection stops sending). They are not harmful and don't use any bandwidth, and should close within two minutes.

 

[dorris]

This is simply all the users that had you in their download list, ie your queue contained them.
once you go offline, each person still attempts a connection to you to try get your queue status or permission to upload, once your machine refuses a connection on that port, they remove you from their list of sources