Diablo® III

Network Issues

As I was randomly reading on wikipedia, I came across an interesting term:

Bufferbloat:

Bufferbloat is a phenomenon in a packet-switched computer network (such as the Internet) when excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. The phenomenon was detailed at least as far back as 1985, but gained more widespread attention starting in 2009.

Bufferbloat occurs when a network link becomes congested, causing packets to become queued in the buffer. In a first-in first-out queuing system, larger buffers result in longer queues and higher latency, but do not improve network throughput and may reduce goodput to zero.

http://en.wikipedia.org/wiki/Bufferbloat

See, I'm not entirely sure we can all blame Blizzard for what's happening. Bufferbloat sounds very much like a big part of the problem I experience. This and several other factors relating to online gaming performance are simply out of their control. Just because you have a fiber connection doesn't mean there won't be switches and routers along the way that are experiencing heavy loads and queuing packets... this is my understanding of the issue anyway - definitely not working for Blizzard with the access to information they have - but this sounds plausible.
Edited by Zero7#1138 on 4/18/2013 7:56 PM PDT
Reply Quote
Its Blizzards problem b/c they have a 10 second disconnect timer in HC.....they need a better fix.....Disconnecting has never been the problem....the 10 second timer is the real problem.
Reply Quote
Agreed, as I know this, but in my other post just now I pointed out that I do in fact perform tracert's regularly, I ping my network, I ping google, everything returns fine, My entire network is static, as well as the DNS, my NIC is configured to 100mbps full duplex, running speed tests always return normal..
it is ONLY with Diablo 3 that I have any issues at all.
Granted, I cannot 100% assure myself it's 100% Blizzard without having all the facts, but come on.. only with Diablo 3? Something isn't right with that.
Reply Quote
04/18/2013 07:54 PMPosted by MASKOAA
the 10 second timer is the real problem.


Then they increase vulnerability surface for abuse.
Reply Quote
04/18/2013 07:57 PMPosted by tbagala
I do in fact perform tracert's regularly, I ping my network, I ping google, everything returns fine, My entire network is static, as well as the DNS, my NIC is configured to 100mbps full duplex, running speed tests always return normal..


If you understand the way packets are routed through the internet then you have probably noticed in your traceroutes that the route your packets take to a constant destination are often travelling through different nodes.

Your local area (home) network is very unlikely to be the bottleneck. More likely the threshold to your ISP from internet backbones.

Again, I want to say, I am mostly speaking out of my hat here.
Reply Quote
Well after next week rolls around and I upgrade to the 60mbps, if i still experience the spikes, I'm also going to give them all my collaborative tracert information and request they reroute me or do something to rectify the latency.
I will eventually figure this out if it takes me all year to do so.
I'm also bought all new cat5e and will rewire everything completely.
It just chaps my !@# I have to jump through all these hoops to play 1 game.
Reply Quote
04/18/2013 07:58 PMPosted by Zero7
the 10 second timer is the real problem.


Then they increase vulnerability surface for abuse.


I don't care if others ruin the experience for themselves, its not like HC has a huge population as is anyways.
Reply Quote
http://queue.acm.org/detail.cfm?id=2076464

GETTYS: I had been hearing similar complaints all along. In fact, Dave Reed [Internet network architect, now with SAP Labs], about a year earlier had reported problems in 3G networks that also appeared to be caused by excessive buffering. He was ultimately ignored when he publicized his concerns, but I've since been able to confirm that Dave was right. In his case, he would see daily high latency without much packet loss during the day, and then the latency would fall back down again at night as flow on the overall network dropped.

"JIM GETTYS: In pulling on a string to figure out why my home router was misbehaving so badly, I discovered that all operating systems—Linux, Windows, and Macintosh alike—also are guilty of resorting to excessive buffering. This phenomenon pervades the whole path. you definitely can't fix it at any single location."

Dave Clark [Internet network architect, currently senior research scientist at MIT] had noticed that the DSLAM (Digital Subscriber Line Access Multiplexer) his micro-ISP runs had way too much buffering—leading to as much as six seconds of latency. And this is something he had observed six years earlier, which is what had led him to warn Rich Woundy of the possible problem.
Reply Quote
Sigh... I'll say it again. The 'lag/dc' issue is that the game uses UDP as the protocol. There's a lot more to this than just a hardware layer.

In UDP there is no guarantee that the packets sent will reach the destination, in the order that they were sent, or even that they will reach the destination at all. The code is then written in a way that the game can 'continue' even if a packet is not received. They need to do it this way in order to make the game playable. I believe this is the case for most of online games.
Reply Quote
From the same link:

WEAVER: It's actually a pretty straightforward test that allowed us to capture all that data. In putting together Netalyzr at ICSI, we started out with a design philosophy that one anonymous commenter later captured very nicely: "This brings new meaning to the phrase, 'Bang it with a wrench.'" Basically, we just set out to hammer on everything—except we weren't interested in doing a bandwidth test since there were plenty of good ones out there already.

I remembered, however, that Nick McKeown and others had ranted about how amazingly over-buffered home networks often proved to be, so buffering seemed like a natural thing to test for. It turns out that would also give us a bandwidth test as a side consequence. Thus we developed a pretty simple test. Over just a 10-second period, it sends a packet and then waits for a packet to return. Then each time it receives a packet back, it sends two more. It either sends large packets and receives small ones in return, or it sends small packets and receives large ones. During the last five seconds of that 10-second period, it just measures the latency under load in comparison to the latency without load. It's essentially just a simple way to stress out the network.

We didn't get around to analyzing all that data until a few months after releasing the tool. Then what we saw were these very pretty graphs that gave us reasonable confidence that a huge fraction of the networks we had just tested could not possibly exhibit good behavior under load. That was a very scary discovery.
Reply Quote
04/18/2013 08:11 PMPosted by Poxy
I believe this is the case for most of online games.


Then why do I experience spikes ONLY with D3 and nothing else ever?
Reply Quote
04/18/2013 07:54 PMPosted by MASKOAA
the 10 second timer is the real problem.


Man, back when I played hardcore D2, I could Alt + F4 faster than a mongoose kills a striking snake. Looking back, I realize that I was cheating my young self out of the full hardcore experience.

I would love to see the DC problem fixed in a non-exploitable way, but getting rid of the timer will lead to too much abuse. Perhaps shortening it would work - if you're trying to quit because you're in real trouble perhaps you'll die in 3 or 5 seconds, anyway - but I think it's important not to give people the ability to quit instantly.

I'd much rather see a Starcraft-style auto-pause feature if you disconnect. But I know exactly nothing about computers, so I have no idea if that's feasible for D3.
Reply Quote
In UDP there is no guarantee that the packets sent will reach the destination, in the order that they were sent, or even that they will reach the destination at all. The code is then written in a way that the game can 'continue' even if a packet is not received. They need to do it this way in order to make the game playable. I believe this is the case for most of online games.


But this is a good thing, and perhaps an explanation to what muxers do with clients of different latency: nothing. The problem, I think, is buffering packets instead of dropping them completely - that is why bufferbloat has a compounding effect on the problem.
Reply Quote
04/18/2013 08:15 PMPosted by tbagala
Then why do I experience spikes ONLY with D3 and nothing else ever?


Grab that tool they were using in the link and see if you are getting the 6 seconds lag spikes from your ISP buffering as they were on verizon fios.
Reply Quote
04/18/2013 08:15 PMPosted by tbagala
I believe this is the case for most of online games.


Then why do I experience spikes ONLY with D3 and nothing else ever?


Do you have any idea how much #$%^ D3 probably needs to send compared to other online games? Just look at everything that's going on on the screen. It may be something to do with that... but that's just a stab in the dark.

May also be different server locations... p2p online games vs client/server architectures... could be any one of a million things.
Reply Quote
04/18/2013 08:16 PMPosted by Sunshine
I'd much rather see a Starcraft-style auto-pause feature if you disconnect.


I'd like to see an auto pause as well. I have no idea if it's a feasible fix or not. An auto pause on DC would have saved 3/4 of my level 60 character deaths. Or an offline mode, but now I'm just pissin' in the wishing well again.
Reply Quote
http://n1.netalyzr.icsi.berkeley.edu/analysis/

Results

Summary of Noteworthy Events + –
Minor Aberrations –

Certain TCP protocols are blocked in outbound traffic
We detected at least one proxy
Network packet buffering may be excessive
Some DNS resolvers appear to be down
Your computer's clock is slightly slow

Address-based Tests + –
NAT detection (?): NAT Detected +
Local Network Interfaces (?): OK +
DNS-based host information (?): OK +
NAT support for Universal Plug and Play (UPnP) (?): Yes +
Reachability Tests + –
TCP connectivity (?): Note –
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.

Direct TCP access to remote SMTP servers (port 25) succeeds, but does not return the expected content.

This suggests that your network enforces a mandatory SMTP proxy which may or may not allow you to send email directly from your system. This is probably a countermeasure against malware abusing infected machines for generating spam. You ISP also likely provides a specific mail server that is permitted. Also, webmail services remain unaffected.

The client received the following reply instead of our expected header:
"220 TBAGPC avast! SMTP proxy ready. "
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP connections to remote POP3 servers (port 110) succeed, but do not receive the expected content.

The client received the following reply instead of our expected header:
"+OK avast! POP3 proxy ready. "

Direct TCP access to remote RPC servers (port 135) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.

Direct TCP access to remote NetBIOS servers (port 139) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP connections to remote IMAP servers (port 143) succeed, but do not receive the expected content.

The client received the following reply instead of our expected header:
"* OK avast! IMAP Proxy "
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.

Direct TCP access to remote SMB servers (port 445) is blocked.

This is probably for security reasons, as this protocol is generally not designed for use outside the local network.
Direct TCP connections to remote SMTP/SSL servers (port 465) succeed, but do not receive the expected content.

The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP connections to remote authenticated SMTP servers (port 587) succeed, but do not receive the expected content.

The client received the following reply instead of our expected header:
"220 TBAGPC avast! SMTP proxy ready. "
Direct TCP connections to remote IMAP/SSL servers (port 993) succeed, but do not receive the expected content.

The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP connections to remote POP/SSL servers (port 995) succeed, but do not receive the expected content.

The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP access to remote PPTP Control servers (port 1723) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
UDP connectivity (?): OK +
Traceroute (?): OK +
Path MTU (?): OK +
Hidden Proxy Detection (?): Warning –

Netalyzr detected the following proxies:

Port: 25 , Response Time: 4 ms
Port: 110 (POP3), Response Time: 4 ms
Port: 143 (IMAP), Response Time: 4 ms
Port: 465 (SMTP/SSL), Response Time: 4 ms
Port: 587 (Authenticated SMTP), Response Time: 4 ms
Port: 993 (IMAP/SSL), Response Time: 3 ms
Port: 995 (POP/SSL), Response Time: 4 ms
Reply Quote
Network Access Link Properties + –
Network performance (?): Latency: 42 ms, Loss: 0.0% +
TCP connection setup latency (?): 39ms +
Background measurement of network health (?): no transient outages +
Network bandwidth (?): Upload 2.4 Mbit/s, Download 1.5 Mbit/s +
Network buffer measurements (?): Uplink 3400 ms, Downlink 5900 ms –
We estimate your uplink as having 3400 ms of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
We estimate your downlink as having 5900 ms of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large downloads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large downloads at the same time.
HTTP Tests + –
Address-based HTTP proxy detection (?): OK +
Content-based HTTP proxy detection (?): OK +
HTTP proxy detection via malformed requests (?): OK +
Filetype-based filtering (?): OK +
HTTP caching behavior (?): OK +
JavaScript-based tests (?): OK +
DNS Tests + –
Restricted domain DNS lookup (?): OK +
Unrestricted domain DNS lookup (?): OK +
DNS resolver address (?): OK +
DNS resolver properties (?): Lookup latency 100 ms +
Direct probing of DNS resolvers (?) –
Your system is configured to use 3 DNS resolver(s).
The resolver at 7.254.254.254 is not responding to requests.
The resolver at 209.124.193.100 (rdns-01.eatel.net) can process all tested types. Requests from this resolver come from 209.124.193.100. This resolver requries 104 ms to fetch a result from our server and 120 ms to return a result from its cache. It does not validate DNSSEC. It does not wildcard NXDOMAIN errors. The resolver reports a number of additional properties. Show them.
The resolver at 209.124.193.101 (rdns-02.eatel.net) can process all tested types. Requests from this resolver come from 209.124.193.101. This resolver requries 103 ms to fetch a result from our server and 18 ms to return a result from its cache. It does not validate DNSSEC. It does not wildcard NXDOMAIN errors. The resolver reports a number of additional properties. Show them.
DNS glue policy (?): OK +
DNS resolver port randomization (?): OK +
DNS lookups of popular domains (?): OK +
DNS external proxy (?): OK +
DNS results wildcarding (?): OK +
DNS-level redirection of specific sites (?): OK +
Direct probing of DNS roots (?): OK +
IPv6 Tests + –
DNS support for IPv6 (?): OK +
IPv4, IPv6, and your web browser (?): No IPv6 support +
IPv6 connectivity (?): No IPv6 support +
Network Security Protocols + –
DNSSEC Network Transport Tests (?): OK +
DNSSEC Support from the DNS Roots (?): OK +
Host Properties + –
System clock accuracy (?): Warning –
Your computer's clock is 12 seconds slow.
Browser properties (?): OK +
Uploaded data (?): OK
Reply Quote
There you have the culprit I'd say.

Also, I think your antivirus sandboxed your net connection (guessing) and runs everything through a proxy that might add another layer of buffering aside from operating system and network buffering.

Nice work tbagala.
Edited by Zero7#1138 on 4/18/2013 8:38 PM PDT
Reply Quote
I have requested sticky for this thread :)
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]