Jump to content

Oshunj

Members
  • Content Count

    10
  • Joined

  • Last visited

  • Speed Test

    My Results

About Oshunj

  • Rank
    New Member
  • Birthday September 19

Profile Information

  • Gender
    Female
  • Location
    Plano Texas
  • Interests
    reading, learning mac, all things apple
  1. Oshunj

    Hello-New

    mytest.tiff Thanks for the help. These are some cool troubleshooting tools. Looks like uverse has me paying for service that I am not able to get due to bandwith traffic. Starting to really get upset! Used another site I was told about ICSI Netalyzr http://netalyzr.icsi.berkeley.edu/index.html Interesting that both diagnostics say something about packet buffering... Summary of Noteworthy Events – Minor Aberrations Certain TCP protocols are blocked in outbound traffic Network packet buffering may be excessive The NAT's DNS proxy doesn't fully implement the DNS standard Not all DNS types were correctly processed Address-based Tests + NAT detection (?): NAT Detected Local Network Interfaces (?): OK DNS-based host information (?): OK NAT support for Universal Plug and Play (UPnP) (?): Not found 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) is prohibited. This means you cannot send email via SMTP to arbitrary mail servers. Such blocking is a common countermeasure against malware abusing infected machines for generating spam. Your ISP likely provides a specific mail server that is permitted. Also, webmail services remain unaffected. 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 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 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 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 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 NTP servers (port 123) is allowed. Direct UDP access to remote OpenVPN servers (port 1194) is allowed. Direct UDP access to remote MSSQL servers (port 1434) is allowed. Traceroute (?): OK It takes 20 network hops for traffic to pass from our server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses. ip-10-244-132-2.ec2.internal (0 ms) ip-10-1-42-1.ec2.internal (0 ms) ip-10-1-34-70.ec2.internal (0 ms) 216.182.232.70 (0 ms) * * * * dca-edge-18.inet.qwest.net (2 ms) 192.205.32.29 (6 ms) cr2.wswdc.ip.att.net (45 ms) cr1.attga.ip.att.net (46 ms) cr2.dlstx.ip.att.net (45 ms) rd3tx81crs.ip.att.net (46 ms) 151.164.98.170 (44 ms) 151.164.98.170 (44 ms) cr82.auttx.ip.att.net (45 ms) * * * Path MTU ([url=http://n4.netalyzr.icsi.berkeley.edu/info_mtu.html]?): 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: 79ms Loss: 0.0% The round-trip time (RTT) between your computer and our server is 79 msec, which is good. We recorded no packet loss between your system and our server. TCP connection setup latency (?): 82ms The time it takes your computer to set up a TCP connection with our server is 82 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 1.4 Mbit/sec, Download 13 Mbit/sec Your Uplink: We measured your uplink's sending bandwidth at 1.4 Mbit/sec. This level of bandwidth works well for many users. Your Downlink: We measured your downlink's receiving bandwidth at 13 Mbit/sec. This level of bandwidth works well for many users. During this test, the applet observed 2 reordered packets. Network buffer measurements ([url=http://n4.netalyzr.icsi.berkeley.edu/info_buffer.html]?): Uplink 790 ms, Downlink 140 ms We estimate your uplink as having 790 msec of buffering. This level can in some situations prove somewhat high, and you may experience degraded performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. Real-time applications, such as games or audio chat, may also work poorly when conducting large uploads at the same time. We estimate your downlink as having 140 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 We can successfully look up a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server. Unrestricted domain DNS lookup (?): OK We can successfully look up arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server. Direct DNS support (?): OK All tested DNS types were received OK. Direct EDNS support (?): OK EDNS-enabled requests for small responses are answered successfully. EDNS-enabled requests for medium-sized responses are answered successfully. EDNS-enabled requests for large responses are answered successfully. DNS resolver address (?): OK The IP address of your ISP's DNS Resolver is 151.164.1.26, which resolves to dnsnode14-x4.rcsntx.sbcglobal.net. Additional nameservers observed for your host: 151.164.1.9, 151.164.1.12, 151.164.1.2, 151.164.1.11, 151.164.1.23. DNS resolver properties (?): Lookup latency 130ms Your ISP's DNS resolver requires 130 msec to conduct an external lookup. It takes 77 msec for your ISP's DNS resolver to lookup a name on our server. Your resolver correctly uses TCP requests when necessary. Your resolver is using QTYPE=A for default queries. Your host or resolver also performs IPv6 queries in addition to IPv4 queries. Your DNS resolver requests DNSSEC records. Your DNS resolver advertises the ability to accept DNS packets of up to 4096 bytes. Your DNS resolver can successfully receive a smaller (~1400 byte) DNS response. Your DNS resolver can successfully receive a large (>1500 byte) DNS response. Your DNS resolver can successfully accept large responses. Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner. Your NAT has a built-in DNS proxy. Some or all specialized DNS types checked are not properly interpreted by the NAT's DNS proxy. The following tested queries were blocked/failed: EDNS0 (DNS extensions)You appear to be using a NAT/gateway manufactured by 2Wire. Your ISP's DNS server cannot use IPv6. No transport problems were discovered which could affect the deployment of DNSSEC. Direct probing of DNS resolvers (?) Your system is configured to use 1 DNS resolver(s). The resolver at 192.168.1.254 was unable to process the following tested types:EDNS0 (DNS extensions)Medium (~1300B) TXT recordsLarge (~3000B) TXT recordsLarge (~3000B) TXT records fetched with EDNS0It does not validate DNSSEC. DNS glue policy (?): OK Your ISP's DNS resolver does not accept generic additional (glue) records — good. Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers. Your ISP's DNS resolver does not follow CNAMEs. DNS resolver port randomization (?): OK Your ISP's DNS resolver properly randomizes its local port number. The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis. DNS lookups of popular domains (?): OK 78 of 79 popular names were resolved successfully. The most likely cause for failed forward lookups is a transient network issue. Show all names. 8 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names. 6 popular names have a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names. DNS external proxy (?): OK Your host ignores external DNS requests. DNS results wildcarding (?): OK Your ISP correctly leaves non-resolving names untouched. DNS-level redirection of specific sites (<a href=http://n4.netalyzr.icsi.berkeley.edu/info_dns_mitm.html" target="_blank">?): OK Your ISP does not appear to be using DNS to redirect traffic for specific websites. IPv6 Tests + DNS support for IPv6 (?): OK IPv6 Connectivity (?): No IPv6 Support IPv6 TCP connectivity (?): Not Executed IPv6 and Your Web Browser (?): No IPv6 Support IPv6 Path MTU (?): Not Executed IPv6 Traceroute (?): Not Executed Host Properties + System clock accuracy (?): OK Browser properties (?): OK Uploaded Data (?): OK
  2. Oshunj

    Hello-New

    okay, i think i may have been downloading a file when i tested just before now. I redid the test and now am even more horrified :::.. Oshunj's Download Test Results ..::: Download Connection is:: 4551 Kbps about 4.6 Mbps (tested with 4 MB) Download Speed is:: 569 kB/s Tested From:: https://testmy.net/ (Dallas, TX USA) Validation Link:: https://testmy.net/db/IKekEn Test Time:: 2011-04-02 14:18:46 GMT -7 1MB Download in 1.8 Seconds - 1GB Download in ~31 Minutes - 79X faster than 56K Tested from a 4 MB file and took 7.373 seconds to complete Running at 91% of hosts average (Sbcglobal.net) User Agent:: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0 [!] large file
  3. Oshunj

    Hello-New

    Auto download/upload Large Test thoughts?
  4. Oshunj

    Hello-New

    Oh no. The first one I transposed the testmy.net url. It is not a good representation. The second one I listed was from the correct url I called uverse and suddenly my rates were up past 15Mbps. But my internet connection still seems slow to render webpages. I'm skeptical of these results right now.
  5. Oshunj

    Hello-New

    From the Terminal - But I guess that's from my computer too. Don't know how to do it from the VRAD... Last login: Sat Apr 2 08:43:33 on console unknown5855caf3cd9d:~ Oshunj$ tracert -bash: tracert: command not found unknown5855caf3cd9d:~ Oshunj$ traceroute www.testmy.net traceroute to testmy.net (174.120.187.140), 64 hops max, 52 byte packets 1 homeportal (192.168.1.254) 3.930 ms 3.296 ms 3.411 ms 2 108-81-192-2.lightspeed.rcsntx.sbcglobal.net (108.81.192.2) 32.866 ms 30.933 ms 31.945 ms 3 * * * 4 70.143.192.118 (70.143.192.118) 35.862 ms 34.002 ms 34.222 ms 5 12.83.34.1 (12.83.34.1) 34.442 ms 33.748 ms 33.639 ms 6 151.164.101.78 (151.164.101.78) 35.626 ms 33.147 ms 33.411 ms 7 151.164.251.150 (151.164.251.150) 34.349 ms 151.164.251.162 (151.164.251.162) 33.601 ms 151.164.251.150 (151.164.251.150) 33.932 ms 8 po2-20g.ar5.dal2.gblx.net (67.16.136.30) 35.667 ms 33.546 ms 35.548 ms 9 the-planet-dallas.tengigabitethernet6-2.ar5.dal2.gblx.net (67.17.168.94) 34.420 ms 39.266 ms 35.707 ms 10 te2-4.dsr01.dllstx3.networklayer.com (70.87.255.38) 35.295 ms te9-2.dsr02.dllstx3.networklayer.com (70.87.253.30) 35.844 ms te2-4.dsr02.dllstx3.networklayer.com (70.87.255.46) 33.709 ms 11 * * * 12 a.ff.5746.static.theplanet.com (70.87.255.10) 36.697 ms e.ff.5746.static.theplanet.com (70.87.255.14) 37.741 ms a.ff.5746.static.theplanet.com (70.87.255.10) 37.458 ms 13 8c.bb.78ae.static.theplanet.com (174.120.187.140) 35.094 ms 35.573 ms 35.449 ms unknown5855caf3cd9d:~ Oshunj$
  6. Oshunj

    Hello-New

    I did this in Network Utility. Im going to try to do so through the router, if I can Result from the router traceroute 174.120.187.140 with 64 packetsize 1: 108-81-192-2.lightspeed.rcsntx.sbcglobal.net (108.81.192.2) 32 ms 2: * * 3: * * 4: 12.83.34.1 33 ms 5: 151.164.101.78 32 ms 6: 151.164.251.150 32 ms 7: po2-20G.ar5.DAL2.gblx.net (67.16.136.30) 60 ms 8: The-Planet-Dallas.TenGigabitEthernet6-2.ar5.DAL2.gblx.net (67.1 33 ms 9: te9-2.dsr01.dllstx3.networklayer.com (70.87.253.14) 33 ms 10: * * 11: a.ff.5746.static.theplanet.com (70.87.255.10) 34 ms 12: 8c.bb.78ae.static.theplanet.com (174.120.187.140) 34 ms
  7. Oshunj

    Hello-New

    Im sure this aint good!:icon_pale:and yes its still in progress! ============================================ Traceroute has started… traceroute to www.mytest.net (208.87.33.150), 64 hops max, 52 byte packets 1 homeportal (192.168.1.254) 4.120 ms 4.091 ms 2.869 ms 2 108-81-192-2.lightspeed.rcsntx.sbcglobal.net (108.81.192.2) 30.227 ms 31.929 ms 28.522 ms 3 * * * 4 * * * 5 12.83.34.1 (12.83.34.1) 480.802 ms 510.536 ms 531.541 ms 6 12.122.195.241 (12.122.195.241) 530.269 ms 267.474 ms 276.781 ms 7 192.205.36.214 (192.205.36.214) 290.731 ms 192.205.37.126 (192.205.37.126) 144.394 ms 192.205.36.214 (192.205.36.214) 180.057 ms 8 0.ae1.xl3.dfw7.alter.net (152.63.96.46) 195.754 ms 214.973 ms 216.326 ms 9 0.so-7-0-0.xl3.mia4.alter.net (152.63.85.62) 254.324 ms 0.ge-7-3-0.xl3.mia4.alter.net (152.63.1.110) 277.053 ms 297.647 ms 10 tengige0-4-4-0.gw11.mia4.alter.net (152.63.84.162) 311.281 ms 330.523 ms 334.959 ms 11 internet-gw.customer.alter.net (152.179.26.218) 349.338 ms 356.629 ms 405.097 ms 12 * * * 13 24.244.158.2 (24.244.158.2) 104.011 ms 93.904 ms 149.522 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * * * 41 * * * 42 * yes. yes....i know.......here is the real tracert. guess the macosx doesnt give u the end tracert msg Help! ========================================= Traceroute has started… traceroute to testmy.net (174.120.187.140), 64 hops max, 52 byte packets 1 homeportal (192.168.1.254) 3.362 ms 2.937 ms 2.857 ms 2 108-81-192-2.lightspeed.rcsntx.sbcglobal.net (108.81.192.2) 29.618 ms 30.395 ms 30.091 ms 3 * 70.143.192.86 (70.143.192.86) 62.875 ms 32.640 ms 4 * 70.143.192.118 (70.143.192.118) 40.023 ms 37.005 ms 5 12.83.34.1 (12.83.34.1) 35.782 ms * 47.126 ms 6 151.164.101.78 (151.164.101.78) 76.881 ms 85.916 ms 130.298 ms 7 151.164.251.162 (151.164.251.162) 108.019 ms 151.164.251.150 (151.164.251.150) 32.047 ms 151.164.251.162 (151.164.251.162) 33.117 ms 8 po2-20g.ar5.dal2.gblx.net (67.16.136.30) 41.685 ms 32.039 ms 32.852 ms 9 the-planet-dallas.tengigabitethernet6-2.ar5.dal2.gblx.net (67.17.168.94) 39.411 ms 33.671 ms 32.833 ms 10 te7-2.dsr01.dllstx3.networklayer.com (70.87.253.10) 32.656 ms te7-2.dsr02.dllstx3.networklayer.com (70.87.253.26) 32.595 ms te2-3.dsr02.dllstx3.networklayer.com (70.87.255.42) 35.839 ms 11 * * * 12 a.ff.5746.static.theplanet.com (70.87.255.10) 34.917 ms e.ff.5746.static.theplanet.com (70.87.255.14) 33.234 ms a.ff.5746.static.theplanet.com (70.87.255.10) 32.320 ms 13 8c.bb.78ae.static.theplanet.com (174.120.187.140) 35.715 ms 32.406 ms 32.897 ms
  8. Oshunj

    Hello-New

    https://testmy.net/sig/Oshunj.png Check out my tests. Some are on my iphone but Im on Att uverse paying for 18 Mbps......Some button I need to push or something?
  9. Oshunj

    Hello-New

    I have Uverse with Att. Purchased high speed internet. I was just outside the VRAD reach and they did some special extension. I have a 2wire wireless router hooked up in living room. There are two boxes of *stuff*; one outside next to my phone wires on the porch. Another one in the garage. I hook my Mac up via wireless. I understand I wont get 18Mbps but the tests I am doing at all hours of the day/night weekend as well as on the iphone seem to indicate I am not getting anywhere near 5Mbps...... Download Speed up to 18 Mbps is what I am paying for. I would like to get some evidence that I am not receiving the appropriate speed or that my system is not set up correctly. Here are some of my tests: Also uploaded screen shot of speedtest run from dslreports.com speedtestfrom dslreports.tiff
  10. Oshunj

    Hello-New

    I found u by using the mobile speed test. I'm becoming more and more upset at my results using wifi...paying for faster speeds but getting crappy results. Any advice on providing evidence of consistently low download speeds to att?
×
×
  • Create New...