11-29-2010 7:44 PM
I've noticed when using U-Verse Realtime that the Interfaces tab doesn't update when there is heavy utilization...for example, 4HD WAN streaming and a fast-running download in progress. I should be capped at around 32Mbps when doing this... When the download completes, the numbers jump to impossible values (such as exceeding 75Mbps on VDSL downstream) for an update, then return to reasonable values. If I again start downloading another file the updates again stop.
I did read the known issues in the readme where it talked about certain data rate computations being non-functional but I'm not sure if that applies in this case, as ethernet ports and HPNA rates are normally reported. I am using a 3801HGV.
Solved! Go to Solution.
12-01-2010 7:52 PM
I did some additional playing around ... and found that as load increases, my RG becomes less and less responsive to HTTP requests. To the point that if U-verse Realtime is doing a round of requests to gather data, my PCs will stop loading webpages and timeout...as if a DNS query is not being served. I can recreate this with doing HTTP requests to the RG with my browser as well. Established connections continue undisturbed. TV and VOIP are unaffected. When I close U-verse Realtime or cease browser HTTP requests to the RG things return to normal and webpages load quickly as you would expect. The NAT table is no where near taxed when I do this, with only a few entries. Seems to me that my RG is underpowered. Does the 3800 do this, or is this just a 3801 thing?
Just some additional data points if you're interested.
12-01-2010 8:01 PM - edited 12-01-2010 8:12 PM
Are you running 188.8.131.52 Realtime? I believe it is almost totally passive and no longer issues IGMP requests. "U-Verse Realtime is now mostly a passive network application, simply listening on the network for SSDP packets that the STB/DVR unit send out."
12-01-2010 8:30 PM
Yes, under conditions where the RG is very busy, the HTTP requests to the RG will take so long that the timing between individual requests will cause the computed data rates to become progressively more inaccurate.
The RG treats HTTP requests as a low priority task. So switching, routing, etc. all get served first before HTTP requests. If there is a high amount of traffic traversing the RG, especially if the VDSL line is saturated (particularly in the upload direction), the HTTP requests will take too long.
mmullins, you're correct that UVRT as of v184.108.40.206 and higher no longer issues IGMP requests, and instead just listens for SSDP packets, that is for the Channels/Streams data only. The line stats data is still obtained via HTTP requests to the RG.
12-01-2010 8:33 PM - edited 12-01-2010 8:38 PM
I am running 1.6.... under load, the "gathering statistics" takes over a minute sometimes.
My system log in the RG is full of entries like this... I can't vouch for the normalcy of them:
krtlock: thread httpd (tid 342) slow wr held 'device'@0x43fc7f14 for 11.34s
krtlock: slck: httpd (tid 342) httpd (pid 320):
krtlock: [342/320] - 0: 0x409862d5
edit: I think I posted this last entry as you did yours Ok, so it's not just me, it's the RG, and even the latest RG. Doesn't change the fact that it's absurd. My 4 year old D-link router handled 3x as much traffic with a larger NAT table and didn't blink an eye. Oh well, as long as it doesn't interfere with the operation of it under normal conditions.
12-01-2010 8:43 PM - edited 12-01-2010 8:45 PM
The "krtlock" indication I believe stands for "Kernel Thread Lock". I'm guessing here but I believe what this means is that the HTTP request needs to access a shared data structure in the RG's memory that is also being updated by the routing, switching, firewall, NAT, or other process.
As an example, think about the Ethernet statistics byte counts. If the switching process is switching packets from one Ethernet port to another, then every packet that traverses the switch has to go increment the byte counters. Similarly, the HTTP process needs to read the byte counters to build the web page. The counter variable in memory has to have a shared mutex or other device to prevent the two processes from accessing the byte counter at the same time.
Since the switching process has higher priority, if a ton of switching is going on, the HTTP process essentially will have to wait forever because it can't get access to the byte counter variable. Eventually the kernel will kill the HTTP thread since it's basically deadlocked.
You might want to look at your network traffic to make sure that you don't have an inadvertent huge amount of traffic traversing from one Ethernet port to another through the RG. I had an acquaintance with this exact problem -- he had several IP cameras sending video through the RG and it was impacting the internet access speed and TV since there was so much switching going on. Moving the cameras and computers to an external Gigabit switch solved the problem.
12-01-2010 9:08 PM
I thought the same, but in this case a summary of all the activity is:
HPNA: 1 DVR and 3STBs, each pulling a stream, earlier it was 2SD/2HD.
Port 1: Uplink to gigabit switch, with idle NAS and 1 active PC, downloading Fedora 14 from http://fedora.mirrors.tds.net at 1.9MB/sec.
Port 2: Idle laptop
Wireless: Idle iMac, idle Wii and 2 Blackberries with some sporadic email checking
Phone: Not in use.
I don't think there's anything out of the ordinary going on here, it just surprises me that the RG doesn't have more "spunk". Thanks for the responses. I'll keep as much "internal" traffic as I can away from the RG switch but there's not much even now.
Having service trouble? There is an app for that! Use our troubleshooting tool or text myATT to 8758 to download the app on your device.It allows you to troubleshoot in the palm of your hand - quickly and easily!You will also find some helpful articles below.
© 2017 AT&T Intellectual Property.This link will open a new window All rights reserved. AT&T, Globe logo, Mobilizing Your World and DIRECTV are registered trademarks of AT&T Intellectual Property and/or AT&T affiliated companies. All other marks are the property of their respective owners.
Congratulations! You earned the Liz badge!