Results 1 to 6 of 6

Thread: Lots of packet loss

  1. #1

    Lots of packet loss

    I am not noticing any browsing issues and also when i am gaming or on vent i am getting good ping. I just notice that when playing games online my bullet registration is very bad and when i go offline i notice bullet registration
    I have also messed around with dr.tcp and mtu settings and nothing

    No packet loss when doing tracert
    And no packet loss when running ping test from pingtest.com


    The ICSI Netalyzr
    Introduction Analysis Results
    Result Summary +/– (help)

    Recorded at 06:06 PDT (13:06 UTC), Oct 10 2010. Permalink. Client/server transcript.
    Summary of Noteworthy Events –
    Minor Aberrations
    Certain TCP protocols are blocked in outbound traffic
    Network packet buffering may be excessive
    Your computer's clock is slightly fast
    Address-based Tests +
    NAT detection (?): NAT Detected
    DNS-based host information (?): OK
    Reachability Tests –
    TCP connectivity (?): Note
    Direct TCP connections to remote FTP servers (port 21) failed.

    This is commonly due to how a NAT or firewall handles FTP traffic, as FTP causes unique problems when developing NATs and firewalls.

    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 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
    Basic UDP access is available.

    The applet was able to send fragmented UDP traffic.

    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 OpenVPN servers (port 1194) is allowed.
    Direct UDP access to remote MSSQL servers (port 1434) is allowed.
    Path MTU (?): OK
    The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.

    Network Access Link Properties –
    Network latency measurements (?): Latency: 32ms Loss: 0.0%
    The round-trip time (RTT) between your computer and our server is 32 msec, which is good.
    We recorded no packet loss between your system and our server.
    TCP connection setup latency (?): 38ms
    The time it takes your computer to set up a TCP connection with our server is 38 msec, which is good.
    Network background health measurement (?): no transient outages
    During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages.
    Network bandwidth measurements (?): Upload 490 Kbit/sec, Download 6.9 Mbit/sec
    Your Uplink: We measured your uplink's sending bandwidth at 490 Kbit/sec. This level of bandwidth works well for many users.
    Your Downlink: We measured your downlink's receiving bandwidth at 6.9 Mbit/sec. This level of bandwidth works well for many users.
    Network buffer measurements (?): Uplink 3300 ms, Downlink 300 ms
    We estimate your uplink as having 3300 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 300 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic.
    HTTP Tests +
    Address-based HTTP proxy detection (?): OK
    Header-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
    Direct EDNS support (?): OK
    DNS resolver address (?): OK
    DNS resolver properties (?): Lookup latency: 120ms
    DNS glue policy (?): OK
    DNS resolver port randomization (?): OK
    DNS lookups of popular domains (?): OK
    DNS external proxy (?): OK
    DNS results wildcarding (?): OK
    Last edited by Ukranian20; 10-10-10 at 06:14 PM.

  2. #2
    Still having this problem

  3. #3
    Ohh Hell yeah.. Sava700's Avatar
    Join Date
    Feb 2002
    Location
    Somewhere
    Posts
    24,052
    I think you posted info that really doesn't say much... where are you located? What is your ISP and what is the package you sub to?

    Post a TCP analyzer log also along with a few speedtests from say www.speedtest.net

  4. #4
    R.I.P. Nov 2015 RaisinCain's Avatar
    Join Date
    Jun 2009
    Posts
    1,951
    What version of Windows are you running?

  5. #5
    Windows 7 i also had the same issue in windows xp.

  6. #6
    Ohh Hell yeah.. Sava700's Avatar
    Join Date
    Feb 2002
    Location
    Somewhere
    Posts
    24,052
    Quote Originally Posted by Ukranian20 View Post
    Windows 7 i also had the same issue in windows xp.
    You've not answered anything that I asked for... posting the info I needed would have gave the OS you were running and a whole lot more.

Similar Threads

  1. Sonicwall L2 enhanced mode, pinging WAN from LAN
    By Aijaz Baig in forum comp.security.firewalls
    Replies: 0
    Last Post: 06-29-10, 08:31 AM
  2. Packet Loss during peak hours
    By dave228 in forum General Broadband Forum
    Replies: 14
    Last Post: 02-03-10, 10:25 PM
  3. Huge packet loss
    By bologne in forum General Broadband Forum
    Replies: 6
    Last Post: 09-22-09, 04:21 AM
  4. Packet Loss And An Isp Whom Doesn't Listen!
    By UltimateHigh1 in forum General Broadband Forum
    Replies: 40
    Last Post: 09-27-08, 07:27 PM
  5. Replies: 4
    Last Post: 10-22-07, 10:11 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •