Packet loss getting to qrz.com

Anyone else seeing large packet losses getting to qrz.com? I noticed this the other day during the RTTY contest. HRD's digithing does an xml look up to fill in contact info. I was getting this long delay which sort of hangs digital master 780. Because of this I did a little sniffing the path to qrz.com. I am seeing 8ms latency up to IP address 204.29.12.27 (Nashville switch) from that address I see 20.7 average latency. Not bad. Off network I frequently see 50ms so this is good. Next hop is qrz.com. WOW! That hop is un-measurable because of the packet losses over 50%. Just terrible. I"m not sure why the path looks like it does. How is it the Nashville network jumps off directly to qrz.com? I can't really tell if this is an issue with the QRZ isp or something with the Nashville switch jump off to the site directly. Anyone else seeing these problems? PingPlotter (free or pro) is a nice tool for measuring latency or loss. I have the free version. Check it out from your location and let me know if your results are better than mine.

 

Just using the system command "ping", with a couple of websites I checked, I get ping return times of approximately 600 - 700 ms, which is normal for my satellite Internet link.

Pinging QRZ.com results in 100 % timeout and packet loss.

I can use QRZ.com website ok, but XML does not work.

 

XML works for me but just BARELY. It is so slow to respond that I am considering finding some alternative to callsign look ups. At this point QRZ seems almost unusable. I have good internet conductivity with a 300M fiber connection which seems to do reasonably well to every place BUT qrz xml lookups. FYI - file uploads to the log book work fine. No problem moving a file with 50 contacts up to qrz logbook but looking stuff up is painfully slow.

 

I now have HRD looking up callsign information at hamcall.net, where I found I had already set up a free account.

Lookups are still very slow, maybe 20 seconds or so, but I still have no returns from qrz.com

I pinged hamcall.net and get a "normal" return.

I have a support ticket with qrz.com in progress. Latest is that there appears to be a DNS problem at my ISP.

 

Well I don't have any dns problem. Frankly if the problem is with DNS if you are using windows just put an entry in your "hosts" file and be done with it. Either that or use the IP address for the application you are using for the look up. HRD's logbook has not such flexibility and has a "fixed" hard coded callsign look up set up. (ugly) Still you can fix the dns in windoze if that is truly the issue. It is NOT the issue for me. Fixing and using the hosts file in windows is a bit tricky but you should be able to figure it out. Copy the file to a place you have edit rights, modify it and then copy it back to the original location \windows\system32\drivers\etc\hosts. Anyway that will solve the dns but it won't improve the qrz responsible time.

 

Yesterday XML lookup via ACLog 6.4 was totally unusable crawling along and resulting in connection timeouts.

What method do I use to log a formal trouble ticket for This paid service?

 

GOOD QUESTION! I get it that some modes (FT8) have resurrected interest and activity on the bands, logging programs, and look-ups but the performance for xml is almost unusable at times. Ya have to wonder if it is database performance or an ISP issue. I am seriously considering picking up a callsign database on dvd and parking it on a local SS SATA drive. Clearly the thing should be refreshed monthly to be helpful but at this point it is either run my own or investigate the other online lookup alternatives. Maybe this isn't news to serious award chasers but it is a new issue for me.

 

I tried https://xml.qrz.com/xcheck
and https://xmldata.qrz.com/xcheck
as advised by the QRZ Support Team, but both return "This site cannot be reached". I get the same result on two PCs and a phone, all connected to the Internet via home wifi and satellite link.
I checked the "hosts" file, and there was nothing in there except a couple of examples.
The latest from the Support Team (a week ago) is "Ticket Elevated to QRZ Headquarters for support."
My QRZ.com callsign information lookup in HRD Logbook all stopped working for me on the 7th Feb. The website works normally.

 

Just a guess, but, aws hosted websites can't be "ping"ed; I get 100% loss trying qrz.com too.

I tried several off-site ping services and had the same result.

 

Have you tried;

• In the open prompt, type “ipconfig /flushdns” (without the quotes). ?

 

Right so "checking" the hosts file doesn't do anything. Here is the idea: In the hosts file add an entry for qrz. As I said you likely can't edit the hosts file where it is. Copy it, add the following, save it then copy your modified file back to the original location. Win7 and win10 are rude about folder permissions and the copy back will generate a warning but it will still copy. Verify your copy is the file in the original location when you are done.

BTW - site cannot be reached is NOT the same as a site cannot be found error message. "Cannot be reached" sounds more like a routing issue than a DNS issue.

# Modified hosts file
# Add qrz IP address here if they change later you will have to fix this
23.23.229.197 qrz.com
107.21.98.143 xlmdata.qrz.com
# This should eliminate any sort of DNS issue on your end.

 

Good call. You are correct. The sites won't answer the echo request. That means 100% ping loss should be universal. (funny some folks answered the survey question that they aren't seeing any ping losses. : )

 

Ok, thanks Don and Brian for the assistance.

I first read Don's suggestion to use the "flushdns" command. This I did, after checking first that the XML Account Check page was still not working. Still nothing, but the Windows Troubleshooter did tell me that the connection to the Internet was broken at the modem. So, I did a power reset on the satellite modem and wireless router. After this all came back up, I was then able to open and use the XML Account Check page.
I used the "flushdns" from the other PC, not the one I use for my station.
The station PC was fired up, HRD loaded, and XML was working again! After doing a number of lookups in HRD Logbook, I opened my QRZ Account Profile to check the XML Lookups counter was incrementing. It was, so I am satisfied that the XML lookup function was working again.
Lookup data still takes around ten seconds to appear, but that is how it was before it stopped working.

Now, which operation restored function, the DNS Flush, or the reset of the modem and router?

 

Brian,
Thanks for the DNS routing info for the local Hosts file.
I'll know where to look for that now if I see DNS issues in future.

 

Great. I hope that solves your issue.
FYI - The XML look-ups tonight are VERY snappy! Man I hope it stays like it is tonight. Perfect!