mudmanc4

I hope the purified comment helps you understand. The multi test here is pulling from more than one resource at a time. From real world locations. Real data, in the attempt to show what a true connection stream appears as. testing more than one connection , more thn one stream, more than one thread. Look into how to activate or use firefox multi threading.

Excellent observation not to mention the realities your speaking. As normal browsing rarely taxes a good connection, as pages and assets are cached on various levels, from within the browser, to any one or many CDN networks along the path, yet data flow itself, such as a youtube video (could be a poor example) after in which the page is loaded, and the initial image / link within the youtube frame is loaded, dynamically, then the play image/link is initiated by pressing the button, it calls the URI for the video and starts the stream (more going on then just this) If you have ever seen the video 'buffering', in other words, loading enough data prior to displaying, this is most times a significant deduction to realize poor network flow at some point in the path.

The multi threaded test is setup to push the connection and browser to the limits, which rely on hardware performance themselves, and to supply the test participant with a real world hard result. This test function is however not setup or meant to print results that make the user believe anything outside of very specific qualifications concerning data TX/RX paths, yet fluent or not so fluent transmissions.

Pgoodwin1 said it nicely. With the same token, considering the data we access can and does pull from various locations globally. Therefore many times it is more than necessary to have the ability to test from / to multiple geographical locations to verify possible choke points in a network. To gain insight as to your connection specific global weight, testmy.net has featured what it coins as 'multi' or multiple threaded tests, simultaneously pulling from as many as nine (9) specifically located test servers placed around the world, in some of the most highly connected fiber backbone sectors. With this, you are able to chose as little as one test point, with any combination of the nine, or select **all locations. This type of testing is mimicking how the web browser performs in real time as you browse sites that, as most are, implementing code which pulls resources from as little as one to the possibility of unlimited global resources. Printing unparalleled real world results. This test resource, located at multi geographical location testing has the ability to inform you as to not only how well your ISP is peering with local as well as geographical providers, but how the chosen path is performing on any specific resource. ** Dallas, TX US => testmy.net (shortcut: select by itself for auto mix) Washington D.C. => east.testmy.net Cloudflare (Global CDN) => cloud.testmy.net San Jose, CA US => west.testmy.net Google Pagespeed (Global CDN) => google.testmy.net Dallas, TX US => dallas.testmy.net (DNS resolution for targeted selection) London, GB => uk.testmy.net Melbourne, AU => au.testmy.net Hong Kong, CN => cn.testmy.net

If I had more experience with your type of connection, check back, I'm sure someone that has should reply.

You might want to try testing the specific server stand alone, in other words, instead of using the auto test, select the test server, then choose the size of the tests you wish to run.

Since you are using verizon wireless to connect, do you have a mobile hotspot? I ask because you mentioned new computer, not a smartphone or tablet. A brief on your device as well as connection would be helpful.

Looks like you may have made a few changes to your network? Seems your tests are getting better.

When you run a download test, you should be able to see what testmy.net calls 'TIP' Also, you might want to follow the link https://testmy.net/trace to get an actual or more detailed trace/ping

Nothing like taking things half way. Sure a lot of work went into this, appears to have gotten hung up in a bubble of short sighted marketing managers and internal politics. The oldest most widely utilized data transfer agents since the serial cable, has been bastardized. Can anyone say pinout instead of physical attributes? Duh-me ? Oo

Varnish cache/proxy along with either a network failure or firewall rule could also have these results. Though, this appears to be a mobile device that has attempted to load the standard page.

Everything is good on my end.

To all, have yourselves a good day. Myself I'm thankful that I can see the sun and clouds, listen to the wind moving through whatever's in it's way, and most of all that I have the ability to share.

This will likely find nothing, but run eset's online scanner. I trust it and use it. If you have a 2.0 port use it. Or attach the cam to a hub that is attached. And find a generic or old driver for the cam instead of what you are using.

Hope you had a great day as well TriRan

Keep smiling and never look back or we can't see where were going.

Myself I've found Backuppc to be a viable very stable solution. Set and forget. Takes a bit of configuration depending on the platform being backed up, linux, of course very simple, using any of the standard secure connection protocols, windows the same but takes a good bit more time to get the OS itself ready to accept connections.

Well don't be a stranger then If you can find the time keep the thread updated yes ?

I'll have to agree. However I fail to find how this relates to this thread.

You might represent your overall experience by placing the average within your sig. What you currently show in your sig is a mis representation. Had a look at your results and it's obvious there is a lack of throughput during normal hours.

These are standard. The timing out could be any number of other issues, since the service you are trying to use, already has settings to overcome any configs that would adversely confuse itself.

What you are seeing is likely devices in place to prevent DOS attacks, synfloods or simply that ICMP packets are being tossed since they have the lowest priority. Or the UDP packets are timing out before they even reach the destination. (TTL) You could try a different flags to either get past the firewall (which also may be set to ignore or drop specific packets), or extend the TTL, change packet type ect... traceroute -I x.x.x.x traceroute -T x.x.x.x traceroute -T -m 60 x.x.x.x The latter will raise the TTL You might want to do this from the router, as windows capabilities are somewhat different.

For the sake of getting this off my mind I decided to go ahead and say it; as simple as I can to avoid a technical conundrum... As a network admin, one would surely be well aware results shown locally will not always match gateway results. We know packets are differentiated between one another on various levels throughout the route, once said packets reach any 'destination' (which there are many in it's travels) header bits may or may not be included / stripped, reordered ect. Therefore the possibility of catching an exact real time congruent match on throughput is very thin. As well as variations between calculations performed (after the fact) locally. (machine dependent latency / local filtering due to firewalls, routers, OS specific settings and load across a plethora of levels not to even mention QOS on more levels imaginable) Stopping eons short of any technicals here, when we alter the very data we seek to explore in any way, or it's resulting computed findings, on any level, this defeats the very reason we initiated the test to begin with, since altered data within the flow is exactly what we were looking for to start with. And should be considered null and void. Therefore we look for "real world" results. What is actually happening. The entire process as a whole while surfing, uploading or downloading, streaming, basically every day usage, never distorts , never alters or flaunts, it just is. If i look at myself in the mirror, and choose to not see the grey hairs on my chin in the morning, and try to convince myself they are still their original color, I would call that mental masturbation , not reality.

I believe this has much to do with the means in which the ISP and net as a whole handles the data itself. Keeping the data flowing in both directions rx/tx as evenly as possible. For a lack of proper terminology.

Since I don't care for assumptions, what were the results (if any) of any one or more of the techs that visited, as far as actual usage on their machines? Such as testing / actual streaming ect... And if no data there, do you have another machine locally that you have the same issues with. Have you run traceroutes to the game servers / streaming sites your using, to locate lagging hops? Run them from router as well as local machine. Ping any server / website on the other side of the country from you, using the 'n' flag example~ ping -n 25 testmy.net