Sign in to follow this  
Followers 0
Mindovermaster

Windows 7 Networking: Upload

73 posts in this topic

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

update your LAN drivers.... also check windows firewall settings...

Share this post


Link to post
Share on other sites

Updated drivers to latest version, Firewall settings are all turned off. Still no dice. I can't get an upload test. Meaning, AFAIK, that I am not getting very good upload on this system only.

Share this post


Link to post
Share on other sites

329 views and only remixed replied? Geez, I'm tearing out my hair about this! Please guys, help!

Share this post


Link to post
Share on other sites

Does the testmy.net site work ok on your Windows PC?

Share this post


Link to post
Share on other sites

can you try a different network card?

Share this post


Link to post
Share on other sites

I would look to firewall or antivirus suites/security software your running to be the problem

Share this post


Link to post
Share on other sites

Does the testmy.net site work ok on your Windows PC?

Umm, no?

can you try a different network card?

The network card is not the issue. I booted a Ubuntu Live-CD and did a testmy.net test and it worked with flying colors.

I would look to firewall or antivirus suites/security software your running to be the problem

I disabled MSE, just took off msconfig startup. I have no firewall.

Share this post


Link to post
Share on other sites

I disabled MSE, just took off msconfig startup. I have no firewall.

Windows firewall?

Share this post


Link to post
Share on other sites

so you have no other security software? Only MSE, I wouldn't worry too much about it to be honest -- do a file download from this box and another machine on your network via file sharing, is that working? Then its prob just security issue with either flash or java depending on site your using or port problem.

have to do a sniff to see what speedtest.net actually uses for upload - I would guess udp? Could be a problem with that -- look more into the details of the site your using for details of how the upload test is actually done so you can troubleshoot what might be causing that to fail.

sniff of the traffic never hurts. Im not home currenty or even on my own machine so can look deeper myself - but when I get home I can fire up a sniff and try a few different speed test sites to see how they differ in testing the upload speed and which ones might work for you if speedtest.net does not.

Share this post


Link to post
Share on other sites

Windows firewall?

http://windows.microsoft.com/en-US/windows/products/security-essentials

so you have no other security software? Only MSE, I wouldn't worry too much about it to be honest -- do a file download from this box and another machine on your network via file sharing, is that working? Then its prob just security issue with either flash or java depending on site your using or port problem.

have to do a sniff to see what speedtest.net actually uses for upload - I would guess udp? Could be a problem with that -- look more into the details of the site your using for details of how the upload test is actually done so you can troubleshoot what might be causing that to fail.

sniff of the traffic never hurts. Im not home currenty or even on my own machine so can look deeper myself - but when I get home I can fire up a sniff and try a few different speed test sites to see how they differ in testing the upload speed and which ones might work for you if speedtest.net does not.

speedtest uses java and flash. testmy just uses flash I think.

Share this post


Link to post
Share on other sites
Summary of Noteworthy Events  + [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url] 

Major Abnormalities [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?

[list]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#DNSNX"]Your DNS resolver returns IP addresses for names that do not exist [img=http://n2.netalyzr.icsi.berkeley.edu/arr_err.gif][/url]
[/list][/url]


Minor Aberrations [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?

[list]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#tcp_connectivity"]Certain TCP protocols are blocked in outbound traffic [img=http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif][/url]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#udp_connectivity"]Fragmented UDP traffic is blocked [img=http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif][/url]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#latency"]The measured packet loss was somewhat high [img=http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif][/url]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#BufferResult"]Network packet buffering may be excessive [img=http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif][/url]
[*][url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#resolverProbing"]Not all DNS types were correctly processed [img=http://n2.netalyzr.icsi.berkeley.edu/arr_wrn.gif][/url]
[/list]

Address-based Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] ? 


NAT detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_nat_detect.html"]?[/url]): NAT Detected [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Local Network Interfaces ([url="http://n2.netalyzr.icsi.berkeley.edu/info_local_interface.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS-based host information ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_hostinfo.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


NAT support for Universal Plug and Play (UPnP) ([url="http://n2.netalyzr.icsi.berkeley.edu/info_upnp.html"]?): Yes [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

Reachability Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url] [/url]


TCP connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_tcp_connectivity.html"]?): Note [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]

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) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is allowed.
Direct TCP access to remote NetBIOS servers (port 139) is allowed.
Direct TCP access to remote IMAP servers (port 143) is allowed.
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 allowed.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.
The applet 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 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.[/url]


UDP connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_udp_connectivity.html"]?): Note [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]

Basic UDP access is available.
The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.The maximum packet successfully sent was 1472 bytes of payload.
The applet was able to receive fragmented UDP traffic.
Direct UDP access to remote DNS servers (port 53) is allowed.
Direct UDP access to remote NTP servers (port 123) is allowed.
Direct UDP access to remote NetBIOS NS servers (port 137) is allowed.
Direct UDP access to remote NetBIOS DGM servers (port 138) is allowed.
Direct UDP access to remote IKE key exchange servers (port 500) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote Slammer servers (port 1434) is allowed.
Direct UDP access to remote L2 tunneling servers (port 1701) is allowed.
Direct UDP access to remote IPSec NAT servers (port 4500) is allowed.
Direct UDP access to remote RTP servers (port 5004) is allowed.
Direct UDP access to remote RTCP servers (port 5005) is allowed.
Direct UDP access to remote SIP servers (port 5060) is allowed.
Direct UDP access to remote VoIP servers (port 7078) is allowed.
Direct UDP access to remote VoIP servers (port 7082) is allowed.
Direct UDP access to remote SCTP servers (port 9899) is allowed.
Direct UDP access to remote Steam gaming servers (port 27005) is allowed.
Direct UDP access to remote Steam gaming servers (port 27015) is allowed.[/url]


Traceroute ([url="http://n2.netalyzr.icsi.berkeley.edu/info_traceroute.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Path MTU ([url="http://n2.netalyzr.icsi.berkeley.edu/info_mtu.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

Network Access Link Properties  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url] [/url]


Network latency measurements ([url="http://n2.netalyzr.icsi.berkeley.edu/info_latency.html"]?): Latency: 59ms Loss: 7.0% [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]

The round-trip time (RTT) between your computer and our server is 59 msec, which is good.
We recorded a packet loss of 7%. 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 7.0% of the packets appear to have been lost on the path from your computer to our servers.[/url]


TCP connection setup latency ([url="http://n2.netalyzr.icsi.berkeley.edu/info_tcp_latency.html"]?): 61ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Network background health measurement ([url="http://n2.netalyzr.icsi.berkeley.edu/info_burst_loss.html"]?): no transient outages [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Network bandwidth ([url="http://n2.netalyzr.icsi.berkeley.edu/info_bandwidth.html"]?): Upload 970 Kbit/sec, Download 6.7 Mbit/sec [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Network buffer measurements ([url="http://n2.netalyzr.icsi.berkeley.edu/info_buffer.html"]?): Uplink 6100 ms, Downlink 3400 ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]

We estimate your uplink as having 6100 msec 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 3400 msec 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  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] ? [/url]


Address-based HTTP proxy detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_addr.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Content-based HTTP proxy detection ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_header.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


HTTP proxy detection via malformed requests ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpproxy_malformed.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Filetype-based filtering ([url="http://n2.netalyzr.icsi.berkeley.edu/info_content_filters.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


HTTP caching behavior ([url="http://n2.netalyzr.icsi.berkeley.edu/info_httpcache.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


JavaScript-based tests ([url="http://n2.netalyzr.icsi.berkeley.edu/info_javascript.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]
DNS Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url] 


Restricted domain DNS lookup ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_restricted.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]


Unrestricted domain DNS lookup ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_unrestricted.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Direct DNS support ([url="http://n2.netalyzr.icsi.berkeley.edu/info_direct_dns.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Direct EDNS support ([url="http://n2.netalyzr.icsi.berkeley.edu/info_edns_connectivity.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]


DNS resolver address ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver.html"]?[/url]): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS resolver properties ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver_behavior.html"]?): Lookup latency 100ms [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


Direct probing of DNS resolvers ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_resolver_probes.html"]?) [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]

Your system is configured to use 1 DNS resolver(s).
The resolver at 192.168.0.1 (clboh-dns-cac-112) could not process the following tested types:[list]
[*]Medium (~1300B) TXT records
[*]Large (~3000B) TXT records
[/list]It does not validate DNSSEC. It wildcards NXDOMAIN errors. Instead of an error it returns the following IP address(es): 69.16.143.110, 66.152.109.110. The resolver reports a number of additional properties. [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]Show them.[/url][/url]


DNS glue policy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_glue.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS resolver port randomization ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_random.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS lookups of popular domains ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dnslookups.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS external proxy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_proxy.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


DNS results wildcarding ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_wildcarding.html"]?): Warning [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]?[/url]


Your ISP's DNS server returns IP addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 69.16.143.110, which does not resolve. You can inspect the resulting HTML content [url="http://n2.netalyzr.icsi.berkeley.edu/uploaded/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8/key=nxpage"]here[/url].
There are several possible explanations for this behavior. The most likely cause is that the ISP is attempting to profit from customer's typos by presenting advertisements in response to bad requests, but it could also be due to an error or misconfiguration in the DNS server.
The big problem with this behavior is that it can potentially break any network application which relies on DNS properly returning an error when a name does not exist.
The following lists your DNS server's behavior in more detail.[list]
[*]www.{random}.com is mapped to 69.16.143.110.
[*]www.{random}.org is mapped to 69.16.143.110.
[*]fubar.{random}.com is correctly reported as an error.
[*]www.yahoo.cmo [sic] is mapped to 69.16.143.110.
[*]nxdomain.{random}.netalyzr.icsi.berkeley.edu is correctly reported as an error.
[/list][/url]


DNS-level redirection of specific sites ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_mitm.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]


Direct probing of DNS roots ([url="http://n2.netalyzr.icsi.berkeley.edu/info_dns_roots.html"]?[/url]): [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

IPv6 Tests  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] ? [/url]


DNS support for IPv6 ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_dns.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


IPv4, IPv6, and your web browser ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_javascript.html"]?): No IPv6 support [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url][/url]


IPv6 connectivity ([url="http://n2.netalyzr.icsi.berkeley.edu/info_ipv6_connectivity.html"]?): No IPv6 support [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]
Host Properties  [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url] [img=http://n2.netalyzr.icsi.berkeley.edu/yelred_off.gif] ? 
[/url]


System clock accuracy ([url="http://n2.netalyzr.icsi.berkeley.edu/info_system_clock.html"]?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]
[/url]


Browser properties (<a href="http://n2.netalyzr.icsi.berkeley.edu/info_browser_properties.html" target="_blank">?): OK [url="http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-4697-cfbad52c-fb15-4813-b1b8#"]+[/url]

Uploaded data ([url="http://n2.netalyzr.icsi.berkeley.edu/info_upload.html"]?[/url]): OK

Share this post


Link to post
Share on other sites

Update: I ran the same test as above on my Linux rig, I get the exact same outcome. So, my network is not to blame, as I understand it. Maybe I should just reinstall Windows...

Share this post


Link to post
Share on other sites
Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.

"The applet 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.

"Latency: 59ms Loss: 7.0%"

"We recorded a packet loss of 7%. This loss is very significant and will lead to serious performance problems"

"Fragmented UDP traffic is blocked"

The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT.The maximum packet successfully sent was 1472 bytes of payload.

The applet was able to receive fragmented UDP traffic.

So you got the same result when running it on linux? Strange - I don't get any of those responses at all - and if your machine/network was working correctly you sure and the hell would not have 7% packet loss. And you should be able to send and recv fragmented udp - that would explain your issue with upload tests. So your Sure your linux box got the same exact results?

"Direct TCP access to remote PPTP Control servers (port 1723) is allowed."

"Network latency measurements (?): Latency: 36ms Loss: 0.0% "

"The applet was able to send fragmented UDP traffic.

The applet was able to receive fragmented UDP traffic."

"We recorded no packet loss between your system and our server."

Share this post


Link to post
Share on other sites

Yeah, the same exact results all the way through.

Share this post


Link to post
Share on other sites

Well you got a serious issue if your having 7% packet loss. Well beyond anything that speed test will show you.

I would redo the test, maybe it was just congestion to their server? You can not have 7% packet loss and expect to have a good day ;)

Share this post


Link to post
Share on other sites

I'm not having a good day without that. ;)

Edit: Actually, now I looked deeper, I get 9% packet loss on my linux rig. While that is bad, I am not noticing any lag.

Share this post


Link to post
Share on other sites

What router do you have and does it show decent connection stats?

Share this post


Link to post
Share on other sites

You shouldn't have any packet loss! 0% you could live with say a few packets here or there, maybe 1% -- but 7-9% would make the internet SUCK!

Is this over wireless or wired?

Share this post


Link to post
Share on other sites

I have a D-Link DGL4500. Would the connection stats be in the logs?

@BudMan: Both of them are wired systems.

Share this post


Link to post
Share on other sites

Well that packet loss sucks - this is much more of an issue than you can not get some upload test to work. After you packet loss is fixed we can look the upload issue

Share this post


Link to post
Share on other sites

Should I just reset my modem and/or router and see if I benefit from it?

Share this post


Link to post
Share on other sites

can not hurt to do a reset. What is worse that is going to happen? You still have the issue ;)

Share this post


Link to post
Share on other sites

Try changing your cables does this affect it?

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.