Jump to content

Question

Posted

Hey,

I have been getting some really bad connections when playing Minecraft. It is just so laggy. Now, I thought, why don't I do a speedtest? Png was fine, at 10ms. Download was fine, at 20Mbps But the upload just hanged, never finishing.

I test this on other computers around the house, and I get fine upload time at 900Kbps. I try switching the cable on this system. No dice.

So, I thought, why not just try a different OS? I pop my Ubuntu 12.04 x64 disk in, and ran another speedtest on it. Had to run from testmy.net because I didn't have java on there. This ran fine. So It wasn't my hardware, but my software.

Now, what is the problem with Windows? I did recently clone it to my new Samsung 830 128GB from my OCZ Vertex 60GB. But everything seems to work no problem.

Do I need to flush something?

Share this post


Link to post
Share on other sites

72 answers to this question

  • 0

Posted

I used it as a replacement for blackice, i.e. for the application protection and whatnot.
Doesn't matter anyway now as I use linux.

Share this post


Link to post
Share on other sites
  • 0

Posted

There a different test site where I can get a second opinion? My internet isn't crappy.

Share this post


Link to post
Share on other sites
  • 0

Posted

[quote name='Mindovermaster' timestamp='1349791976' post='595235541']
There a different test site where I can get a second opinion? My internet isn't crappy.
[/quote]

I get an all green pass result apart from not being able to accept fragmented packets using the ICSI test

Share this post


Link to post
Share on other sites
  • 0

Posted

Well if nobody else seems to be seeing packet loss to this test site, I would have to disagree and say yes your internet is crappy ;)

I can duplicate your fragmented udp issue by turning off scrubbing in my firewall, and it has no effect on packet loss. So that is not the cause of the reported packet loss. So I am really curious what part of the test is having issues that it reports such a high amount of packet loss.

Now if multiple people off multiple isps were all showing packet loss on this test site, then sure maybe there is something wrong with the site. But clearly that is not the case - so yeah your internet connection is crappy. Or there is a path between you and the site that is crappy, which is hard to fix. If you have problems accessing anything on the internet where you see that level of packet loss then clearly something is wrong - even if its not between your box and your isp.
1 person likes this

Share this post


Link to post
Share on other sites
  • 0

Posted

Crappy, in what way? I have never noticed a slowness in Internet slowness, nor in gaming. So slow crappy is not in my vocabulary.

If you do not know "why" this is happening, then how can you assess the information?

So, how can I know if my ISP is having trouble connecting with that site? I ran multitude tests on other sites, I get 0% packet loss on all other of them. Explain that.

I NEED another opinion.

Share this post


Link to post
Share on other sites
  • 0

Posted

[quote name='Mindovermaster' timestamp='1349795661' post='595235717']
Crappy, in what way? I have never noticed a slowness in Internet slowness, nor in gaming. So slow crappy is not in my vocabulary.

If you do not know "why" this is happening, then how can you assess the information?

So, how can I know if my ISP is having trouble connecting with that site? I ran multitude tests on other sites, I get 0% packet loss on all other of them. Explain that.

I NEED another opinion.
[/quote]

tracert netalyzr.icsi.berkeley.edu

See if there is a problem with the journey to that site, if not, theres your answer

Here's mine to compare, and the test says my connection is fine

[code]C:\Windows\system32>tracert netalyzr.icsi.berkeley.edu

Tracing route to netalyzr.icsi.berkeley.edu [192.150.187.31]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms DD-WRT [192.168.1.2]
2 5 ms 5 ms 5 ms 217.32.144.64
3 16 ms 31 ms 26 ms 217.32.144.94
4 10 ms 10 ms 10 ms 213.120.181.34
5 11 ms 10 ms 10 ms 217.41.169.181
6 11 ms 10 ms 10 ms 217.41.169.107
7 10 ms 10 ms 10 ms 109.159.251.121
8 21 ms 23 ms 23 ms core1-te-0-13-0-13.ealing.ukcore.bt.net [109.159.251.167]
9 14 ms 14 ms 14 ms transit2-xe3-1-0.ealing.ukcore.bt.net [62.6.200.183]
10 14 ms 14 ms 14 ms t2c4-xe-10-2-0.uk-eal.eu.bt.net [166.49.168.41]
11 17 ms 17 ms 17 ms xe-9-0-0.edge4.London2.Level3.net [212.187.201.133]
12 151 ms 151 ms 150 ms ae-3-3.ebr1.London1.Level3.net [4.69.141.189]
13 150 ms 150 ms 151 ms vlan104.ebr2.London1.Level3.net [4.69.143.98]
14 150 ms 151 ms 151 ms ae-42-42.ebr1.NewYork1.Level3.net [4.69.137.70]
15 151 ms 151 ms 151 ms ae-61-61.csw1.NewYork1.Level3.net [4.69.134.66]
16 154 ms 153 ms 153 ms ae-62-62.ebr2.NewYork1.Level3.net [4.69.148.33]
17 153 ms 153 ms 153 ms 4.69.135.185
18 151 ms 152 ms 153 ms ae-91-91.csw4.SanJose1.Level3.net [4.69.153.14]
19 154 ms 151 ms 151 ms ae-4-90.edge1.SanJose1.Level3.net [4.69.152.206]
20 150 ms 150 ms 151 ms CENIC.edge1.SanJose1.Level3.net [4.53.16.186]
21 161 ms 160 ms 159 ms dc-svl-core1--svl-isp1-10ge.cenic.net [137.164.47.133]
22 168 ms 169 ms 169 ms sfo-agg1--svl-agg2-10g.cenic.net [137.164.22.26]
23 161 ms 161 ms 162 ms dc-ucb--sfo-agg1-10ge.cenic.net [137.164.50.17]
24 170 ms 170 ms 170 ms t1-3.inr-201-sut.Berkeley.EDU [128.32.0.65]
25 172 ms 172 ms 172 ms ge-0-0-0.inr-667-sut.Berkeley.EDU [128.32.0.81]
26 177 ms 162 ms 208 ms router3-fast1-0-0.ICSI.Berkeley.EDU [169.229.0.138]
27 161 ms 226 ms 213 ms router1-vlan5.icsi.berkeley.edu [192.150.187.249]
28 190 ms 200 ms 209 ms roland.icir.org [192.150.187.31]

Trace complete.[/code]

Share this post


Link to post
Share on other sites
  • 0

Posted

So in the client report on the top of the report you should see the details on WHY it is saying your having packet loss. Just saying there is packet loss doesn't tell us where it happening.

Now since other users are not having it reported, removes their servers and hardware until the path becomes different on how you get there and how I get there. There is going to be a point where we become common in our paths. It might just be the server and its gateway, or it could be a few hops before where it is common.

Now keep in mind they have the client check different locations - there is quite a bit of testing dns testing, maybe your having packet loss reported because of your client talking to specific dns? And not really to their test server. Without seeing the details of the client report, I posted a snip of mine a few posts back. Can you post the whole client side report, or PM it to me if your worried about what info might be in there - but pretty much it should just be your local IP (router) or your private client IP so should be able to post it all.

Maybe the report of packet loss is not really relevant?? Then again any report of packet loss I would suggest you investigate because at that level your going to have issues to be sure related to where they are seeing it. Maybe where they are seeing is not something you do? Which is why you have not noticed it. Then again maybe you do it every day, and just come to think that is how the internet is suppose to work ;)

Share this post


Link to post
Share on other sites
  • 0

Posted

[code]Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Master>tracert netalyzr.icsi.berkeley.edu

Tracing route to netalyzr.icsi.berkeley.edu [192.150.187.31]
over a maximum of 30 hops:

1 9 ms 9 ms 9 ms cm-76-46-128-1.wi.res.rr.com [76.46.128.1]
2 8 ms 9 ms 9 ms network-024-160-224-008.wi.rr.com [24.160.224.8]

3 10 ms 10 ms 8 ms tge0-5-0-5.milwwiwaln-asr1.wi.rr.com [24.160.225
.16]
4 12 ms 11 ms 11 ms tge1-1-0.tr00.chctilwc.mwrtn.rr.com [24.160.229.
193]
5 16 ms 14 ms 10 ms ae-6-0.cr0.chi30.tbone.rr.com [66.109.6.206]
6 13 ms 17 ms 15 ms ae-0-0.cr0.chi10.tbone.rr.com [66.109.6.20]
7 11 ms 11 ms 11 ms 107.14.17.192
8 12 ms 11 ms 11 ms 64.57.20.53
9 66 ms 65 ms 64 ms 137.164.129.2
10 73 ms 72 ms 74 ms xe-1-0-0.0.paix0.tr-cps.internet2.edu [64.57.20.
222]
11 73 ms 74 ms 75 ms 137.164.131.94
12 75 ms 75 ms 73 ms dc-svl-core1--svl-px1-10ge-3.cenic.net [137.164.
46.14]
13 76 ms 75 ms 75 ms sfo-agg1--svl-agg2-10g.cenic.net [137.164.22.26]

14 74 ms 76 ms 77 ms dc-ucb--sfo-agg1-10ge.cenic.net [137.164.50.17]

15 75 ms 76 ms 77 ms t1-3.inr-202-reccev.Berkeley.EDU [128.32.0.67]
16 75 ms 83 ms 77 ms ge-1-3-0.inr-667-sut.Berkeley.EDU [128.32.0.83]

17 79 ms 77 ms 89 ms router3-fast1-0-0.ICSI.Berkeley.EDU [169.229.0.1
38]
18 82 ms 103 ms 80 ms router1-vlan5.icsi.berkeley.edu [192.150.187.249
]
19 103 ms 78 ms 111 ms roland.icir.org [192.150.187.31]

Trace complete.

C:\Users\Master>[/code]

Share this post


Link to post
Share on other sites
  • 0

Posted

Didn't know what you meant by client transcript. Should have told me it was a little link on that page.

Share this post


Link to post
Share on other sites
  • 0

Posted

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

[code]
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
[/code]

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.

[code]
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
[/code]

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??

Share this post


Link to post
Share on other sites
  • 0

Posted

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

[code]


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#"]

Share this post


Link to post
Share on other sites
  • 0

Posted

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?

Share this post


Link to post
Share on other sites
  • 0

Posted

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

[/code]

Edit: Im in Wisconsin, USA. Change anything? :p

Share this post


Link to post
Share on other sites
  • 0

Posted

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?

Share this post


Link to post
Share on other sites
  • 0

Posted

[code]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

[/code]

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

Share this post


Link to post
Share on other sites
  • 0

Posted

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

Share this post


Link to post
Share on other sites
  • 0

Posted

Here ya go.

[code]--- 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
[/code]

forgot to add in the test results, lol.

Share this post


Link to post
Share on other sites
  • 0

Posted

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.

Share this post


Link to post
Share on other sites
  • 0

Posted

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

Share this post


Link to post
Share on other sites
  • 0

Posted

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.

Share this post


Link to post
Share on other sites
  • 0

Posted

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?

Share this post


Link to post
Share on other sites
  • 0

Posted

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.