nanobot

Honestly I would pay $10-20/mo for a service (i.e. "TMN Enterprise") where I could add projects, then add buildings/floors/rooms within that project and take sampled results that I can then export either to a file or via an API. It would be nice to have a little parity in concept with the way my Fluke's work, like the below screenshot.
 
Typically, when I use the LIQ-100 or DSX2-8000 I:
1. Setup a project within the device
2. Run a test / measurement
3. Save the test / measurement with the patch number or some other label indication
4. Export into Fluke LinkWare for PC
5. Create the facility structure and sort the results into the proper location
6. Generate a PDF from the results to send to the client
 

 
With TMN, I would imagine (and prefer) a workflow like the following:
 
1. Setup a project
2. Setup the location / further structure, such as the floor, etc.
3. Run a test
4. Save the test to the project (or not) with a name (such as "Room", etc.)
5. Export the results as a CSV, JSON, or have an API to retrieve them so they can be dumped into a PDF later
 
Often, if I'm trying to do a speed test at a client site, I'm doing it either on a client PC, or I'm doing wireless testing with my laptop. Having a platform where I could log the test to my project(s) without having to totally log into TMN would be nice as well. I.e. having some type of Username -> MFA Authenticator app request to save the one result to my projects would be awesome.
 
These are just some thoughts, would be nice to have a speed-test tool I could speak to that functioned in a useful way. Even a "My Projects" would be a great start, at least then I can start using my laptop to do client-site testing and troubleshooting.

You can kinda do that right now, by using identifiers.
 

 
Then take note of the date, later query the database for that date range to only pull the results theoretically from the one site.  Maybe make a separate TMN account for these type of results.
 
I intend on making it much easier to organize in your situation by incorporating sub accounts.  Which will help keep track of multiple overall scenarios.  I like the name you just came up with, My Projects.
 
Bumping this up in my to-do list.

I run a company that does network installation, testing, certification, and remediation, and one of the services I offer currently is a wireless signal map. I also currently run multiple speed-tests from different rooms on each site and aggregate those results into a map as well. At the moment, I run them via Speedtest.net, and save the result into an excel spreadsheet manually.
 
It would be handy if I could use TMN natively for it, by starting a "project" and then being able to label tests by room/location and Wireless connection type (b/g or n/ac most often) so that I can export all the results into one file to pull them into my final report. It would also be nice to have those results long-term, so that if I get a client call-back for another round of testing I can compare to the old project to see if anything has changed.

Curiously, Edge still gets substantially faster results.
 
All these results are the exact same PC. From top to bottom:
 
1. Chrome on Current
2. Chrome on Beta
3. Edge on Beta
4. Firefox on Current
5. Firefox on Beta
 

 
Definitely something funky within my Firefox install, I may have to wipe it.

You know this would actually be really handy feature, especially for the configuration note you mentioned. You can add "identifiers" to your tests right now but I think it would be nicer to have a 200-500 char memo field we could add notes to and see on the tables with our own results.

You are seeing the real speed.
 
Your 3Mbps is what speed you were able to achieve when downloading data from Testmy.net. The 1.2MB/sec you are seeing on the download in your screenshot is what you are able to achieve when downloading from that particular site, and is actually 9.6Mbps.
 
You are seeing different units for the metric:
 
MB/s = Mbps / 8
Mbps = MB/s * 8
 
If the Speedtest.net results were accurate, the 50Mbps would be about 6.25MB/sec for your downloads. You are seeing roughly 1/5 that.
 
This may be an issue with your ISP peering, or it may be an issue of routes between you and where you are downloading your data from. I recommend you try switching TMN test servers and see how that affects your metrics.

It's not "faked" so much as the server that Speedtest chooses is deliberately the closest and fastest server. In some cases, it might still be within your ISP's network, which means what you are testing is you -> ISP, not ISP -> world.

That's not surprising. I'm seeing the same at my data-center. They're running several 100Gbit connections, but they also host a bunch of infrastructure for Netflix and Hulu, and they told me that "due to the significant amount of traffic to several of our customers, you may see bandwidth impacts." I got another ticket this week that said they're recarving up their bandwidth to limit those two in particular. Going to be interesting to see how that goes.

Given that the FIA and IMSA have postponed and rescheduled the seasons, I may have to start watching this to get my racing fix in.

Granted, my team stands no chance in F1 this year, but I still want to watch them lose lol

That's not surprising. I'm seeing the same at my data-center. They're running several 100Gbit connections, but they also host a bunch of infrastructure for Netflix and Hulu, and they told me that "due to the significant amount of traffic to several of our customers, you may see bandwidth impacts." I got another ticket this week that said they're recarving up their bandwidth to limit those two in particular. Going to be interesting to see how that goes.

You might want to have a tech come out with a signaling meter. I had Spectrum send one out Tuesday morning, and my tests went from all-over-the-place to consistent 90-120Mbps. (I pay for 100Mbps and was seeing around that before.)
 
I was getting the same thing you are right now: some tests would come back at 2-10Mbps, some at 100Mbps+. Latencies did the same weird spikes.
 
It turned out that the way they ran my cabling introduced a lot of noise, two bad junctions, and cost me huge signaling levels. The thresholds were red-red-red on his meter when he got here, then after doing a couple quick mods it was blue-blue-blue. I was seeing 10-20% packet loss Monday, now I see <1% packet loss. (It also didn't help that my modem was old-old and one of those "combination" / modem+router+wifi units...the new modem is just a modem.)
 
Here are my results for the last week. That last drop was just before he showed up. This also doesn't include the tests I aborted because things just hung.
 

That's not surprising. I'm seeing the same at my data-center. They're running several 100Gbit connections, but they also host a bunch of infrastructure for Netflix and Hulu, and they told me that "due to the significant amount of traffic to several of our customers, you may see bandwidth impacts." I got another ticket this week that said they're recarving up their bandwidth to limit those two in particular. Going to be interesting to see how that goes.

still trying to work out the bugs, but if you have FIOS by Frontier, CALL THEM!  ?
 
 
STORY TIME:
 
See, back in the day, when FIOS was owned by Verizon, the used to do periodic FREE speed upgrades for their customers. For example, when i signed up with FIOS (Verizon) i had the 25/5 package. After a bit, they upgraded their plans to symmetric. So we than got bumped to 25/25. A few years later, as FIOS became more popular, they upgraded us to 35/35 for free! No fuss , no muss. As time went on, there basic plan was 50/50. Again, upgraded at no charge! ->
After some time, many a year later..... Verizon decided they wanted to focus more on their wireless infrastructure, & get out of 65%(+) of their home networking side of things. ( Wireless is far more lucrative than home internet on many, many levels) They decided to SELL their FIOS to Frontier. Frontier is...... garbage to say the least. I dreaded reading this, as well as the day it would come to fruition...  The customer reviews even before they bought FIOS , were frightful to say the least. i was staggered by what was to come. ->
Hardware? Garbage. Network routing? Garbage. Customer Service? Garbage. Its a complete s*** show.  Log story short, after a couple of painful  years & many, many issues with routers, speeds, billing, credits, tech call outs, etc. i finally received the 500/500 plan.  I fought TOOTH & NAIL to get, because they kept telling me my area was not "provisioned to have such speeds". ->
Being on vacation this week, & on lock down to boot, i decided out of sheer boredom to call Frontier up & find out how much the 1 gigabit plan would run us, additional a month, seeing as how iv'e had the 500/500 for some time now.  Dumbfounded, i find out its only $10.00 more a month!!! FRONTIER wasn't planning on telling people this!? Why would they when they can provide ½ the speed & still charge you damn near the same amount for god knows how long. It used to be a $200 a month up-charge! So call! Find out! Don''t pay more if you don''t have to!
 
On a side note, same day after being "upgraded" to the gigabit speeds, i have a "tier 2" service ticket in because the download speeds are quite erratic. I'm sure after 2 to 3 months, they''ll get this corrected too.. ?
 

Bad news @mudmanc4...teams take 10M PPD to turn Red. ☹️
 
 

 
 

Both of my Supermicro's are up.
 
40 CPU Cores here, and 1 1080TI running.
 

@php Like @mudmanc4 said, I had to add 'client-type' 'advanced' to the expert options. This allows you to get the beta WU's. Estimated production for just my desktop is ~1.3 million PPD, just kicked everything off last night so I'm curious how it'll look over the weekend.
 

 

 

 

 

 
 

@php Like @mudmanc4 said, I had to add 'client-type' 'advanced' to the expert options. This allows you to get the beta WU's. Estimated production for just my desktop is ~1.3 million PPD, just kicked everything off last night so I'm curious how it'll look over the weekend.
 

 

 

 

 

 
 

If you're 2.5 miles from the "home office" (typically an MDF/IDF - main / intermediary data facility), you are outside the "sweet-zone" of ADSL.
 
Typically, (A)DSL sees maximum throughput at 2 miles or less from a MDF/IDF. Basically, the distance between your demarcation point (modem) and your ISP's closet.
 
You're only half-a-mile outside the sweet-zone, so I would still expect you to see reasonable speeds. That said, you might never see a stable 6Mbps, due to ADSL typically using older, buried phone / Cat3 lines. (Unless CenturyLink ran shielded coax/twinax copper or fiber, which I highly, highly doubt.)
 
The burst you see with TMN is likely because the lines are cool, so there's no electromagnetic field around them. Because ADSL is typically Cat3, it's often minimally (if at all) twisted, unshielded, and poor-cabling, so it's easy for the cabling to build an electromagnetic field that interferes with signal transmission. This field won't exist at an idle, it will only exist when data is being transmitted. Once the field has built up (often as quick as 50-2500ns) it starts creating cross-talk and signaling interference, slowing the throughput you can achieve. (Basically, error-rates go up, and as a result more of your bandwidth is spent on handling those errors.)
 
Unfortunately, without replacing the cabling, your speeds probably can't be improved much.
 
All that said, does CenturyLink offer 5Mbps? If so, I would downgrade to that and run some more testing. If their signaling is wonky, you'll see a similar drop (I would expect either 1Mbps or 833kbps drop when you switch if they have a signaling calculation incorrect). If you don't see a drop, save yourself the money and keep the 5Mbps connection. If you see a drop, document it (now, the 5 vs. 6, and then, the x vs. 5). If you still have a drop, call CenturyLink and explain the situation. I have no idea how well they'll assist you, but they should be able to make other accommodations (provide 6Mbps but bill at 5Mbps, for example).

Nice, post-dates my Tier-1 work, which explains it. TIL
 
I can run some testing from here as well, I'm running DHCP-PD, so the ISP assigns a /64 which is then assigned to each device.

If you're 2.5 miles from the "home office" (typically an MDF/IDF - main / intermediary data facility), you are outside the "sweet-zone" of ADSL.
 
Typically, (A)DSL sees maximum throughput at 2 miles or less from a MDF/IDF. Basically, the distance between your demarcation point (modem) and your ISP's closet.
 
You're only half-a-mile outside the sweet-zone, so I would still expect you to see reasonable speeds. That said, you might never see a stable 6Mbps, due to ADSL typically using older, buried phone / Cat3 lines. (Unless CenturyLink ran shielded coax/twinax copper or fiber, which I highly, highly doubt.)
 
The burst you see with TMN is likely because the lines are cool, so there's no electromagnetic field around them. Because ADSL is typically Cat3, it's often minimally (if at all) twisted, unshielded, and poor-cabling, so it's easy for the cabling to build an electromagnetic field that interferes with signal transmission. This field won't exist at an idle, it will only exist when data is being transmitted. Once the field has built up (often as quick as 50-2500ns) it starts creating cross-talk and signaling interference, slowing the throughput you can achieve. (Basically, error-rates go up, and as a result more of your bandwidth is spent on handling those errors.)
 
Unfortunately, without replacing the cabling, your speeds probably can't be improved much.
 
All that said, does CenturyLink offer 5Mbps? If so, I would downgrade to that and run some more testing. If their signaling is wonky, you'll see a similar drop (I would expect either 1Mbps or 833kbps drop when you switch if they have a signaling calculation incorrect). If you don't see a drop, save yourself the money and keep the 5Mbps connection. If you see a drop, document it (now, the 5 vs. 6, and then, the x vs. 5). If you still have a drop, call CenturyLink and explain the situation. I have no idea how well they'll assist you, but they should be able to make other accommodations (provide 6Mbps but bill at 5Mbps, for example).

This is Wi-Fi over 802.11ac (MIMO 1300) -- capped out my 100Mbps internet connection.
 
Windows reports it is allegedly running at 520Mbps, I'll have to prove that one of these days.
 

@CA3LE It only took Apple well over a decade, but Safari finally has Favicon support with the new macOS Mojave / Safari 12 update...
 

 
Thanks,
nanobot

Have you looked at the Google Search Console?
 
https://www.google.com/webmasters/tools/
 
It usually has good information as to why pages aren't indexed, or are prioritized lower than others.
 
Thanks,
EBrown

Regarding the IP thing: @CA3LE if I recall correctly, the SQUID proxy they mention utilizes the `X-Forwarded-For` header, are you perhaps checking that as well?
 
I know I had a similar issue with an Enterprise software application that was logging IP addresses, so I began logging the TCP/IP address and the X-Forwarded-For, as I was getting bizarre results similarly to what you are getting here.
 
I know, for a fact, that the 224.0.0.0/4 address space is Class-D (multicast) so no user should actually have that address, and 240.0.0.0/4 should be Class-E, and that's usually experimental / R&D.
 
Arin is being slow so while I'm looking into these additional details:
 
@C0RR0SIVE: The 250.x.x.x address is part of the experimental space, AFAIK (unless any new RFC's are out) it's used by R&D and for experimental use only.
 
So Arin finally loaded, and I'll give you guys the public URL: https://whois.arin.net/rest/net/NET-240-0-0-0-0/
 
As I thought, this is still in the "special use" range, which should be mostly non-routed (though I don't think there are any bars against routing these addresses, it's just not common).
 
Thanks,
EBrown

So I started nmap up, ran some scans (I'm sure @CA3LE won't mind me running some penetration tests against his server) on the SSL ports, and I couldn't find RC4 on the list of ciphers, at all, but then I did on an SMTPS (465) port, but you shouldn't be affected by that.
 
So I got curious, and researched further, and you said it happens about every 10th website, so I have a few follow up questions:
 
1. Are you using Wireless?
   a. If so, are you using WEP? Apparently RC4 was used in the WEP security standard (which has been an insecurity standard for years now).
2. Are you certain there is no MITM attack against you?
 
For those interested, here's the result of my nmap scan:
 
Elliotts-iMac:~ elliottbrown$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.testmy.net Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-20 18:29 EDT Nmap scan report for www.testmy.net (64.111.22.10) Host is up (0.088s latency). rDNS record for 64.111.22.10: testmy.net PORT STATE SERVICE 443/tcp open https | ssl-cert: Subject: commonName=testmy.net | Subject Alternative Name: DNS:testmy.net | Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2017-07-06T06:00:00 | Not valid after: 2017-10-04T06:00:00 | MD5: 415f 2e2b ee78 0642 6813 4e47 743b 9831 |_SHA-1: ecac a111 d818 d982 1039 acea 2fe4 9b6c c975 ca43 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server |_ least strength: A 465/tcp open smtps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | CBC-mode cipher in SSLv3 (CVE-2014-3566) | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_128_GCM_SHA256 - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_256_GCM_SHA384 - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: F 993/tcp open imaps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D 995/tcp open pop3s | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D Nmap done: 1 IP address (1 host up) scanned in 27.86 seconds Elliotts-iMac:~ elliottbrown$  
The letter after the cipher is a letter from A-F, indicating grade of the cipher (A being best, F being worst), you'll notice there are a few RC4 ciphers under the 465, 993 and 995 ports (graded F appropriately), but all of the TLS ciphers are grade A.
 
The lowest cipher strength (according to nmap) on https://www.testmy.net/ is a grade A, so Chrome should definitely not be flagging this site. (In fact, based on this information, testmy.net would refuse an RC4 cipher connection, period.)
 
You definitely have a different issue going on, and I'm curious as to what that is.
 
Thanks,
EBrown