mudmanc4

@SalmanAhmed , getting removed from the blacklist might be possible, however if this happens I would advise doing the math before running the tests next time, as you have already realized

The big news out of AMD was the launch of Zen, the new high-performance core that is designed to underpin the product roadmap for the next few generations of products. To much fanfare, AMD launched consumer level parts based on Zen, called Ryzen, earlier this year. There was a lot of discussion in the consumer space about these parts and the competitiveness, and despite the column inches dedicated to it, Ryzen wasn’t designed to be the big story this year. That was left to their server generation of products, which are designed to take a sizeable market share and reinvigorate AMD’s bottom line on the finance sheet. A few weeks ago AMD announced the naming of the new line of enterprise-class processors, called EPYC, and today marks the official launch with configurations up to 32 cores and 64 threads per processor. We also got an insight into several features of the design, including the AMD Infinity Fabric.' What’s in a Processor? Today’s announcement of the AMD EPYC product line sees the launch of the top four CPUs, focused primarily at dual socket systems. The full EPYC stack will contain twelve processors, with three for single socket environments, with the rest of the stack being made available at the end of July. It is worth taking a few minutes to look at how these processors look under the hood. On the package are four silicon dies, each one containing the same 8-core silicon we saw in the AMD Ryzen processors. Each silicon die has two core complexes, each of four cores, and supports two memory channels, giving a total maximum of 32 cores and 8 memory channels on an EPYC processor. The dies are connected by AMD’s newest interconnect, the Infinity Fabric, which plays a key role not only in die-to-die communication but also processor-to-processor communication and within AMD’s new Vega graphics. AMD designed the Infinity Fabric to be modular and scalable in order to support large GPUs and CPUs in the roadmap going forward, and states that within a single package the fabric is overprovisioned to minimize any issues with non-NUMA aware software (more on this later). With a total of 8 memory channels, and support for 2 DIMMs per channel, AMD is quoting a 2TB per socket maximum memory support, scaling up to 4TB per system in a dual processor system. Each CPU will support 128 PCIe 3.0 lanes, suitable for six GPUs with full bandwidth support (plus IO) or up to 32 NVMe drives for storage. All the PCIe lanes can be used for IO devices, such as SATA drives or network ports, or as Infinity Fabric connections to other devices. There are also 4 IO hubs per processor for additional storage support. In a dual socket arrangement, each CPU uses 64 PCIe lanes in Infinity Fabric mode to communicate with each other. This means there is still a total of 128 PCIe lanes to be used inside the system, but the total memory support has doubled. Going BIG and Attacking The Market: All The Cores, Please AMD is launching a total of nine parts aimed at dual socket use, and three parts for single socket servers. This is consummate with AMD’s strategy of stating that 90-95% of all servers in use today are either single or dual socket, and there will not be quad-socket options on AMD. The goal here is that some of the single socket processor options from AMD could easily replace dual-socket servers for a lower TCO and simplifying the environment by offering more memory and more IO than what is currently on the market. The new processors from AMD are called the EPYC 7000 series, with names such as EPYC 7301 and EPYC 7551P. The naming of the CPUs is as follows: EPYC 7551P EPYC = Brand 7 = 7000 Series 30/55 = Dual Digit Number indicative of stack positioning / performance (non-linear) 1 = Generation P = Single Socket, not present in Dual Socket So in the future we will see EPYC 7302 processors, or if AMD scales out the design there may be EPYC 5000 processors with fewer silicon dies inside, or EPYC 3000 with a single die but for the EPYC platform socket (obviously, those last two are speculation). But starting with the 2P processors: AMD EPYC Processors (2P) Cores Threads Frequency (GHz) L3 DRAM PCIe TDP Price Base All Max EPYC 7601 32 / 64 2.2 2.7 3.2 64 MB 8-Ch DDR4 2666 MT/s 8 x16 128 PCIe 180W >$4000 EPYC 7551 32 / 64 2.0 2.6 3.0 180W >$3200 EPYC 7501 32 / 64 2.0 ? 3.0 155W 170W ? EPYC 7451 24 / 48 2.3 ? 3.2 180W >$2400 EPYC 7401 24 / 48 2.0 2.8 3.0 155W 170W >$1700 EPYC 7351 16 / 32 2.4 ? 2.9 155W 170W >$1100 EPYC 7301 16 / 32 2.2 ? 2.7 155W 170W >$800 EPYC 7281 16 / 32 2.1 ? 2.7 155W 170W >$600 EPYC 7251 8 / 16 2.1 ? 2.9 120W >$400 All CPUs will have 128 PCIe 3.0 lanes, have access to all 64MB of L3 cache, and support DDR4-2666. AMD continually makes clear that all processors will support all the features involved, and the only differentiation point will be on cores, frequencies, and power. Sitting on top of the stack is the EPYC 7601, sporting 32 cores with 64 threads, a base frequency of 2.2 GHz, an all-core boost of 2.7 GHz and a boost frequency of 3.2 GHz. Depending on the distribution of software across the cores, the chip should be at the boost frequency when fewer than 12 cores are in use, although other factors such as localized temperature in the core may affect this. The next two CPUs look the same, but are slightly different. They both have a base frequency of 2.0 GHz, and a peak frequency of 3.0 GHz. Again, the peak frequency should be active when fewer than 12 cores are active. The differences come in the power: the EPYC 7551 is an 180W part, but the EPYC 7501 is listed as 155W/170W. We were told at the AMD Tech Day for EPYC that this 155W/170W listing is due to the fact that this CPU can support DDR4-2400 memory at 155W or DDR4-2666W memory at 170W. So then we have the EPYC 7551 at DDR4-2666 with a 180W TDP, and the EPYC 7501 at DDR4-2666 with a 170W TDP: we’re trying to extract from AMD if there is another difference for this, given that the EPYC 7501 is priced lower and has a lower TDP, but are waiting to hear a response back. On the 24 core parts, the EPYC 7451 and the EPYC 7401, we have a similar set of differences: the 2.3 GHz part has a base frequency of 2.3 GHz, a maximum boost frequency of 3.2 GHz, and supports 180W, while the 2.0 GHz part has a turbo of 3.0 GHz but has the separate 155W/170W modes again. The EPYC 7401 has an all-core turbo of 2.8 GHz due to having fewer cores, but the threshold for this when in 155W mode is at eight cores. For the 24 core parts, AMD has disabled one core per core complex, leaving 3 per complex (so 6 per die, leading to 24 per chip). The sixteen-core processors disable two cores per CCX, leading to four per die, but still with the full complement of cache and memory channels. These all have reduced frequencies over the bigger chips, and all come in 155W/170W flavors. These processors will not be out on day one, but we are told to expect OEMs offering systems with these chips in late July. The final processor is somewhat of an odd-ball. The EPYC 7251 is an eight-core processor, running at a 2.1 GHz base frequency and a 2.9 GHz base frequency, but at 120W. By comparison, Ryzen 7 1700 is an eight-core processor at 3.0/3.7 GHz frequencies but only at 65W, so what is going on here? As mentioned above, all these EPYC 7000-series are based on quad-die designs, so this processor still has the full 700+mm2 of silicon, access to all 64MB of L3 cache, access to 8 memory channels up to 2TB of memory, and a full set of PCIe lanes. The chip only has one core active per CCX, meaning that core-to-core latency will be higher than normal, but AMD’s strategy here is one about having a ‘memory optimized’ part. Their justification is that some workloads are not compute bound but DRAM bound. Here is the cheapest CPU in the stack, available for under $400 (or two for under $800), but for software that pays for licenses per core but is memory size bound to require 2TB/4TB, or are GPU bound, then this is the processor to get. The final three processors are for single socket systems: AMD EPYC Processors (1P) Cores Threads Frequency (GHz) L3 DRAM PCIe TDP Price Base All Max EPYC 7551P 32 / 64 2.0 2.6 3.0 64 MB 8-Ch DDR4 2666 MT/s 8 x16 128 PCIe 180W >$2000 EPYC 7401P 24 / 48 2.0 2.8 3.0 155W 170W >$1000 EPYC 7351P 16 / 32 2.4 ? 2.9 155W 170W >$700 These SKUs mirror the specifications of the 2P counterparts, but have a P in the name. A Side Note on Performance Claims In our presentations about the launch, AMD wanted to make two things clear: these parts are designed to offer a lot better raw performance (as defined by SPECint) at every price point, and that these parts aren’t designed to compete with the current E5 v4 processors on the market, but with Skylake-SP. The slide that was presented showed this: AMD is claiming up to +70% performance for a dual socket system, especially in the ~$800 CPU market which they predict will be the biggest element for sales. Along with this, AMD claimed that for some parts of the market, only one AMD processor will be needed to replace two Intel processors: In this case, an EPYC 7281 in single socket mode is listed as having +63% performance (in SPECint) over a dual socket E5-2609v4 system. I must stress, these are AMD numbers, and vendor numbers should always be taken with a degree of salt due to the risk of cherry picking. Furthermore, as AMD notes in their endnotes, the Intel numbers have been modified. "Scores for these E5 processors extrapolated from test results published at www.spec.org, applying a conversion multiplier to each published score." So we’re waiting to get the chips ourselves to do our own comparison testing. Source

Suppose you needed to transfer 1TB of data (perhaps your home movie collection) from San Francisco to London. What would be the fastest route? Put the disk on British Airways flight 286 at SFO, or transfer it across the Internet using a 100 Mbps connection? Surprisingly, the answer is the former not the latter. If you had a perfect 100 Mbps Internet connection and could fill it completely with data the transfer would take 22 hours 13 minutes. British Airways make the flight in under 10 hours. But even with a 100 Mbps Internet connection you're unlikely to get 100 Mbps of transfer speed between San Francisco and London. The details of the TCP protocol used on the Internet and the speed of light collude to make the effective transfer speed much lower. To really understand the speed of an Internet connection, be it transferring 1TB of data or downloading a web page, there are two values that you need to know: the bandwidth and the latency. The bandwidth is how much data can be sent on the connection in a unit of time. In the example above the Internet connection has a bandwidth of 100 Mbps, the Boeing 747 has a bandwidth of 222 Mbps (the 1TB carried divided by the flight time). The latency is the 'flight time' of data across the connection. For a connection between London and San Francisco across the Internet the latency will be something like 150ms. That figure is governed and limited by the speed of light. For the 747 the latency is the literal flying time of 10 hours. One thing British Airways ensures while flying the 1TB of data is reliability. The data is very, very unlikely to not arrive in London. The Internet does not provide the same guarantee. As data is transferred across the Internet it gets delayed, lost, corrupted and misordered. So, the Internet's core protocol TCP provides mechanisms to ensure the reliable delivery of data despite the lossy network the data is passing through. It's these mechanisms that slow the transfer of data down and where the speed of light comes into play. (If airlines experienced aircraft loss at the rate the Internet sees packet loss there'd be 28 crashes per day in the US alone). To ensure reliability, TCP breaks data to be sent up into chunks (which are further broken down into packets) and sends chunks of data and then waits for an acknowledgement that the chunk was successfully received. It's while waiting for the acknowledgement that the speed of light comes into play. Imagine that a 65kB chunk of data has been sent across a link with a latency of 150ms. The 65kB take 150ms to reach their destination and the receiving machine sends an acknowledgement that takes a further 150ms to arrive. So 0.3s is taken up making sure that 65KB have arrived successfully; that number is called the Round Trip Time. Those acknowledgement delays significantly hamper connections across long distances (and also from mobile phones). The amount of data that TCP can send in a single chunk is controlled by the Receive Window of the receiver machine. For web surfers that means that the receiving machine controls how much can be sent without acknowledgement. And the combination of Receive Window and Round Trip Time limit the speed at which downloads can occur no matter what the bandwidth is. The maximum throughput of TCP is Receive Window divided by Round Trip Time. For example, on my machine the Receive Window is set at 524,288 bytes meaning that on a slow link from London to San Francisco the fastest download I can get is 524,288 bytes / 0.3s or 14 Mbps. Much less than the 100 Mbps I was hoping to get. So, my 1TB download would actually take more than 6 days! The speed of light really is a limiting factor in downloading. How do you fight the speed of light? Since you can't control the Receive Window the only thing you can do is move your web site closer to the people surfing it. And, of course, that's not practical for most web sites since you'd have to have copies of the web site all over the world. CloudFlare fights the speed of light for you by having data centers around the world. If your site is on CloudFlare then surfers will connect to the data center that's nearest to them. More @ Source by John Graham-Cumming

There are still hundreds of thousands of XP machines running I'm sure. I run into them fairly often myself. Those pesky web requirements keep getting in the way of sunset OS's and browsers. Glad you got that sorted out.

Considering back 15 or even 20 years ago as a whole, we all schooled one another on proper distinctions between kilobit and kilobytes ect. At this point I'm inclined to take @wenfingers thought, until we can run this back to it's true roots, wherever that may reside. I'd like to get @nanobots input on this one.

By the looks of your recent tests, it would appear there are other types of games going on there. I would suggest there is heavy download / upload activity, which could then suggest that when you yourself see slowdowns and disconnects or time out issues, someone is torrenting data at that time. ( In other words, downloading and then sharing files / data publicly ) As normal gaming would most likely not consume ~5Mbps upload , nor effect any normal web browsing on another machine, at the speeds your connection is showing. I would also suggest he knows quite a bit more than you think.

As I understand, MaxMind database is used to cross reference the location, however considering the scale of Earth and it's steady growth in ISP's and connected devices, it is not perfect. But always getting better.

It would be a better opton to isolate your network while testing. Otherwise, unless you have a baselinene already established, and know what to expect while others are using the network.

testmy.net is designed to show real world results, as in internet browsing well as issues within the route. Therefore I'm sorry to say, your question becomes moot in this case. Default testing location or not. See, a real world test, is meant to determine the results as if you were using your connection 'normally' (if that is a real term) considering everyone uses their connection differently. Testmy.net is not designated specifically, to show you how well the lines and networking infrastructure is designed and held up by the ISP, however, it will exploit such flaws as well. I understand completely what you are saying, so don't get me wrong. But as well all should be aware of, testing with as few hops, or within our local, as in ISP network, is more or less useless unless we are specifically targeting the ISP. Which then again, that would not be 'internet' speeds, it would be 'how well are we connected to who we are paying for access to, the rest of the web'. As far as adding geo locations, testmy.net already encompasses this issue, by offering various geographical locations to to to/from.

@Raojia, many feel your pain, not that this is any consolation. Taking a quick look at your recent results, they show mid day when generally people are out and about and not using their connections, decent results. As the day grows older, and more people are at home, degradation is obvious. Likely the beam is oversold. Where the throughput is maxed out. Being the only option is the area, everyone has the same issue. Much as one water line sprinkling a small area works great, but branch off to two or three sprinklers off the same line, and the water spread or pressure goes down. I don't think from what little data there is to be had here, that you can control any or much of this locally. Hence why they ask you to pay for the tech, they already know why this is happening to you.

@carref43 , I've added a graph of all tests taken from you connection ID logged in or not. I see you've just recently joined however. Make sure you are logged in while testing. Nice, steady test results by the way No testmy.net does not require a static IP to log results, however members have their own database. Since you were likely not a member since running the tests you did, therefore not logged in, the tests are not saved in your database. There could possible be means to recover older results, @CA3LE would be the guy to discuss this with.

Spoke with the tech at the company who sells me the units, he said "we've never heard of anything like that, but I'll get back to you after talking to the network guy" , nothing yet lol, so fantastic yes?

Dhaka to Tokyo is roughly ~4800KM as well as an underseas cable, I would visit testmy.net/mirror and test a few other locations for good measure. Not that you will not have a long way to go, but you could find a better route than what you have while testing.

@VinceEdwards, You stated 330MB download speeds, I'v added a graph to your post with all results taken logged in or not. I'm sure you meant to say 330Kbps? What are the speeds you are paying for at the ISP?

@Wiseguy_, I would first use a different browser on the new machine, sometimes extensions and addons cause trouble.

Yes, I've had to resort to setting auto negotiate + DHCP at the head end as well as the internal network for anything to function, obviously there is an issue, but where.

So let me simplify this. 586B would not work on cam #1 586A works fine on cam #1 Where 586A does not work on cam #2 586B works on cam #2 Only 596A works on cam #3 between POE injector and cam; where only 586B will work from POE injector to NVR I have nick named the system Sybil

@hillycat, Chances are the satellite beam is loaded with customers to the max, so each time someone or several customers are using the network for something other than email and browsing, the connection is saturated. Search around for a DSL provider in your area, then come back to testmy.net before getting a plan, and search for results in your area. testmy.net has a very large database to query results from.

@brianellermets, First thing considering Dish is a satellite network, we have to remember the data must travel into the atmosphere from your location, then back down to the repeater into a hardwired network. Where the stream can become corrupt and degradation can occur very easily for a multitude of reasons. It is of course possible there is hardware failure going on, however eliminate as many 'other' possibilities as you can first. In this case i would get a live linux disk or USB block device setup, and boot the machine from this. What this can accomplish is to eliminate any possible issues with the machine such as hidden malware and or browser plugins, that sometimes effect a stable data stream. I would also recommend against recursively restarting the modem. Please post your results after getting a live CD or USB for testing purposes.

As I always do standard by wiring at 568B through the entire network, I'm having an issue I'm curious of. While setting up an 8 channel NVR my first cam refused to get an IP from the NVR subnet, or direct to the switch. However POE was functioning while connected to the PEO switch as the IR's would power up. I assumed I either wired the rj45's improper or pulled past the ~25lb limit of the cable and popped a wire (though common sense and experience tells me otherwise). I rewired the connectors, with no love. Ok, so I have a bad section in the cable (my test unit was left over an hour away on another job) In fact where I am running the very same units, two already installed no issues with 568B I pulled a new line, wired 568B, same outcome. With no real other options I could think of at the time, I went ahead and wired this run 568A, worked flawless. Great, so I mount a second cam, pulled the run (very carefully) and wired it 568A and had the same issue as the 568B run. First things first again, replaced the rj45's with again no joy. While wiring this cam 568B, everything appears fine. Same 1000ft spool, so it's not just one wire, and roughly 150foot each run well under max. None of the above are PTZ cams, however I have several that will go in the network which are. Considering these units require an injector it should be twice the fun not knowing why this is happening. Interestingly enough, I connected one cam via 568B pre made patch cables and everything went fine. Leads me to believe there is something very wrong with the spool, as in extreme inconsistencies in resistance throughout it's length, between #'s 4-5 and #'s 7-8 Or better yet, what facet of the networking twilight-zone am I in here? Anyone come across this issue in the past?

Welcome to testmy.net @ShakTib

@Wario, You might do well gathering more data. Run multiple tests at the various testmy.net mirrors to locate issues.

@Velo @Intertechworks , I have added graphing to each of your posts, which consist of all tests taken according to your individual connection ID's I would suggest that each of you run tests to other testmy.net mirrors , and verify where the issue is located in your paths. Just as you, @Velo have done to show the difference between London and Frankfurt compared to your location. We can verify there is/ was an issue between your current location and the Frankfurt server. So this is all about routing, peering, and global connectivity. Testmy.net will show you on what networks such issues might reside. Many of the flash tests are located on upper tier / edge, internal low traffic networks of ISP's, and even alternate ports such as 8080, where the vast majority of 'the internet' is not routed to. Such tests are valuable for internal network connectivity only. In other words, verifying between you and the ISP only. Not giving a real world result such as testmy.net supplies. When I test, I know I'm connected, I rarely test to my local ISP, unless I'm having a global issue and need to verify there is not a local connectivity issue. I test to see what kind of quality and relationship my ISP has with it's peers, (how valuable the peering is, or how much they pay one another to transfer my data at a high level of service) or other networks the ISP makes deals with in order to obtain an higher and more pure global connection.

@IrishKing , Head over to testmy.net/mirror and set the test to run from New_York

Your spot on there boss, it would be tremendously useful for a better UX through UI to the database.