72 replies to this topic

[+BudMan]

so now your not having your UDP issue?

003.533 test-3| Sending UDP request to n3.netalyzr.icsi.berkeley.edu on port 1948
003.533 test-3| UDP socket at 192.168.0.186:59722
003.591 test-3| Got datagram of 2000 bytes.
003.591 test-3| Can receive UDP fragments successfully

So did you show packet loss in this test?

edit: Ok yup there was loss

We recorded a packet loss of 6%. This loss is very significant and will lead to serious performance problems. It could be due either to very high load on our servers due to a large number of visitors, or problems in your network. Of the packet loss, at least 6.5% of the packets appear to have been lost on the path from your computer to our servers.

The ID was in that what you posted, so I was able to call up the actual report.

edit2: ok this looks like where it reports loss

91.257 test-105| Starting checkPing
091.257 test-105| Start time is 1349792008894
091.257 test-105| Remote server is n3.netalyzr.icsi.berkeley.edu
091.257 test-105| Remote port is 1948
102.903 test-105| All packets sent, waiting for the last responses
105.914 test-105| Now counting up bursts on loss
105.914 test-105| Probing done
105.914 test-105| Sent 200 packets
105.914 test-105| Received 187 packets
105.914 test-105| Average RTT 51.57754
105.914 test-105| Sustained RTT 51.60753
105.914 test-105| Server received 187
105.914 test-105| Packets reordered 0
105.914 test-105| Packets duplicated 0
105.914 test-105| Loss bursts observed 1
105.914 test-105| Send packet size 12
105.914 test-105| Received packet size 27

Not this ping is not a normal icmp ping its a to a specific port 1948, which seems your showing loss too.


Now if you look at test I just ran from my machine.

080.061 test-105| Starting checkPing
080.061 test-105| Start time is 1349799394508
080.061 test-105| Remote server is n3.netalyzr.icsi.berkeley.edu
080.061 test-105| Remote port is 1948
090.211 test-105| All packets sent, waiting for the last responses
093.211 test-105| Now counting up bursts on loss
093.211 test-105| Probing done
093.211 test-105| Sent 200 packets
093.211 test-105| Received 200 packets
093.211 test-105| Average RTT 34.965
093.211 test-105| Sustained RTT 34.96985
093.211 test-105| Server received 200
093.211 test-105| Packets reordered 0
093.211 test-105| Packets duplicated 0
093.211 test-105| Loss bursts observed 0
093.211 test-105| Send packet size 12
093.211 test-105| Received packet size 27

So sent to same port, and 200 packets without any loss. Now curious why your RTT is so HIGH compared to mine - where are you located in the world? But this is why your having reported packet loss - because you sent 200 packets to their server on port 1948, and they only go 187 of them??

[Mindovermaster]

It says I have 6.5% packet lost on the test results. So is something screwing around?

Network latency measurements ([url="http://n3.netalyzr.icsi.berkeley.edu/info_latency.html"]?[/url]): Latency: 52ms Loss: 6.5% [url="http://n3.netalyzr.icsi.berkeley.edu/summary/id=ae81b058-5901-97ccafbc-cf5f-4308-b20a#"]–[/url]

The round-trip time (RTT) between your computer and our server is 52 msec, which is good.
We recorded a packet loss of 6%. This loss is very significant and will lead to serious performance problems. It could be due either to very high load on our servers due to a large number of visitors, or problems in your network. Of the packet loss, at least 6.5% of the packets appear to have been lost on the path from your computer to our servers.

[+BudMan]

Yeah your loosing packets when sent to them on that 1948 port.

I would assume they are just counting hits on their firewall from your IP to that port for this count. Since they don't answer on that port when you do a syn ping to them. You said you have linux right, then use hping and do a syn ping to some other tcp port they have listening on that box. So for example I picked 465 since that is listed as a port they use for testing so it is listening

hping3 -S -p 465 n3.netalyzr.icsi.berkeley.edu
HPING n3.netalyzr.icsi.berkeley.edu (eth0 174.129.176.88): S set, 40 headers + 0 data bytes
len=46 ip=174.129.176.88 ttl=43 id=44218 sport=465 flags=SA seq=0 win=5840 rtt=34.5 ms
len=46 ip=174.129.176.88 ttl=43 id=44219 sport=465 flags=SA seq=1 win=5840 rtt=35.2 ms
len=46 ip=174.129.176.88 ttl=43 id=44220 sport=465 flags=SA seq=2 win=5840 rtt=36.1 ms
len=46 ip=174.129.176.88 ttl=43 id=44221 sport=465 flags=SA seq=3 win=5840 rtt=35.1 ms
len=46 ip=174.129.176.88 ttl=43 id=44222 sport=465 flags=SA seq=4 win=5840 rtt=36.2 ms
len=46 ip=174.129.176.88 ttl=44 id=44223 sport=465 flags=SA seq=5 win=5840 rtt=35.4 ms
len=46 ip=174.129.176.88 ttl=44 id=44224 sport=465 flags=SA seq=6 win=5840 rtt=35.0 ms
len=46 ip=174.129.176.88 ttl=44 id=44225 sport=465 flags=SA seq=7 win=5840 rtt=33.6 ms
len=46 ip=174.129.176.88 ttl=43 id=44226 sport=465 flags=SA seq=8 win=5840 rtt=34.3 ms
len=46 ip=174.129.176.88 ttl=44 id=44227 sport=465 flags=SA seq=9 win=5840 rtt=35.0 ms
^C
--- n3.netalyzr.icsi.berkeley.edu hping statistic ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 33.6/35.0/36.2 ms

Let that run for a while!! are you having issue getting responses back from that?

[Mindovermaster]

master@master-Ubuntu:~$ hping3 -S -p 465 n3.netalyzr.icsi.berkeley.edu
[open_sockraw] socket(): Operation not permitted
[main] can't open raw socket

Edit: Im in Wisconsin, USA. Change anything?

[+BudMan]

you have to be root to do that sort of hping Sorry should of mentioned that

WI, your just north of me - so odd that you would be seeing 118 RTT I believe in a test before, this last one was 50's so not too bad - but sill seems a bit high.. You in the boonies of WI?

[Mindovermaster]

HPING n3.netalyzr.icsi.berkeley.edu (eth0 174.129.176.88): S set, 40 headers + 0 data bytes
len=46 ip=174.129.176.88 ttl=41 id=37374 sport=465 flags=SA seq=0 win=5840 rtt=57.9 ms
len=46 ip=174.129.176.88 ttl=42 id=37375 sport=465 flags=SA seq=1 win=5840 rtt=66.0 ms
len=46 ip=174.129.176.88 ttl=41 id=37376 sport=465 flags=SA seq=2 win=5840 rtt=62.5 ms
len=46 ip=174.129.176.88 ttl=41 id=37377 sport=465 flags=SA seq=3 win=5840 rtt=62.6 ms
len=46 ip=174.129.176.88 ttl=41 id=37378 sport=465 flags=SA seq=4 win=5840 rtt=64.7 ms
len=46 ip=174.129.176.88 ttl=41 id=37379 sport=465 flags=SA seq=5 win=5840 rtt=64.6 ms
len=46 ip=174.129.176.88 ttl=41 id=37380 sport=465 flags=SA seq=6 win=5840 rtt=61.6 ms
len=46 ip=174.129.176.88 ttl=42 id=37381 sport=465 flags=SA seq=7 win=5840 rtt=68.6 ms
len=46 ip=174.129.176.88 ttl=42 id=37382 sport=465 flags=SA seq=8 win=5840 rtt=64.5 ms
len=46 ip=174.129.176.88 ttl=42 id=37383 sport=465 flags=SA seq=9 win=5840 rtt=57.3 ms
len=46 ip=174.129.176.88 ttl=41 id=37384 sport=465 flags=SA seq=10 win=5840 rtt=63.8 ms
len=46 ip=174.129.176.88 ttl=41 id=37385 sport=465 flags=SA seq=11 win=5840 rtt=73.1 ms
len=46 ip=174.129.176.88 ttl=42 id=37386 sport=465 flags=SA seq=12 win=5840 rtt=60.3 ms
len=46 ip=174.129.176.88 ttl=41 id=37387 sport=465 flags=SA seq=13 win=5840 rtt=61.1 ms
len=46 ip=174.129.176.88 ttl=42 id=37388 sport=465 flags=SA seq=14 win=5840 rtt=69.4 ms
len=46 ip=174.129.176.88 ttl=41 id=37389 sport=465 flags=SA seq=15 win=5840 rtt=58.0 ms
len=46 ip=174.129.176.88 ttl=42 id=37390 sport=465 flags=SA seq=16 win=5840 rtt=61.6 ms
len=46 ip=174.129.176.88 ttl=42 id=37391 sport=465 flags=SA seq=17 win=5840 rtt=60.7 ms
len=46 ip=174.129.176.88 ttl=42 id=37392 sport=465 flags=SA seq=18 win=5840 rtt=67.2 ms
len=46 ip=174.129.176.88 ttl=41 id=37393 sport=465 flags=SA seq=19 win=5840 rtt=65.6 ms
len=46 ip=174.129.176.88 ttl=42 id=37394 sport=465 flags=SA seq=20 win=5840 rtt=64.3 ms
len=46 ip=174.129.176.88 ttl=42 id=37395 sport=465 flags=SA seq=21 win=5840 rtt=68.1 ms
^C
--- n3.netalyzr.icsi.berkeley.edu hping statistic ---
22 packets transmitted, 22 packets received, 0% packet loss
round-trip min/avg/max = 57.3/63.8/73.1 ms

I live in southeast Wisconsin. Like 30 miles from the Illinois border

[+BudMan]

Well 22 packets is not what I meant by letting it run for a while - how about 200?

[Mindovermaster]

Here ya go.

--- n3.netalyzr.icsi.berkeley.edu hping statistic ---
232 packets transmitted, 232 packets received, 0% packet loss
round-trip min/avg/max = 52.2/59.0/103.8 ms

forgot to add in the test results, lol.

[+BudMan]

Well seems to be no issues with connectivity there -- odd that test seems to have issues with sending 200, I assume it sends them much faster than the cmd line test does which might be where the problem is.

[Mindovermaster]

Like, I told you, my net isn't crappy. There's your proof.

[+BudMan]

that one test is not really proof

Why do you have issues with their test, when nobody else does? Why is your RTT so high compared to someone that is pretty much same distance from them as you.

but your issue has been resolved - and you seem happy with your results so little point it taking this any further.

[Mindovermaster]

Could it simply be my ISP, Time Warner, that has this problem? Unless someone else has Time Warner on the same subcenter as me, you can't really tell what the problem is, right?

[+BudMan]

Yeah its hard to say why your failing that one test.. Clearly doesn't seem to be a general packet loss issue with your connection, maybe they send the packets too fast and some are getting dropped - this could be your router doing it, could be somewhere in the path dropping them..

Since your not showing any overall packet loss on any other tests, and even doing your best to duplicate the test shows no loss. I wouldn't worry about it too much.

Maybe circle back in a week or two/three and see if issue is still there - throw an email to your isp support or the test maintainers asking what could be the cause of the result.