Reply
Posted Nov 29, 2010
7:44:03 PM
View profile
[U-Verse Realtime] Possible bug?

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.

0
(0)
  • Rate this reply
View profile
Solved
Dec 1, 2010 8:30:34 PM
0
(0)
Expert

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 v1.3.0.0 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.

 

Accepted Solution

[U-Verse Realtime] Possible bug?

1,676 views
7 replies
(0) Me too
(0) Me too
Post reply
Replies
(7)
0
(0)
  • Rate this reply
View profile
Nov 30, 2010 2:08:01 PM
0
(0)
Expert

I will test this on the 3800HGV-B and see if I can duplicate the issue.  It may be something peculiar to the 3801HGV.

 

Re: [U-Verse Realtime] Possible bug?

2 of 8 (1,586 Views)
0
(0)
  • Rate this reply
View profile
Dec 1, 2010 7:52:36 PM
0
(0)
Teacher

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.

Re: [U-Verse Realtime] Possible bug?

3 of 8 (1,532 Views)
0
(0)
  • Rate this reply
View profile
Dec 1, 2010 8:01:39 PM
0
(0)
Scholar
Edited by mmullins_98 on Dec 1, 2010 at 8:12:11 PM

Are you running 1.6.0.0 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."

Re: [U-Verse Realtime] Possible bug?

[ Edited ]
4 of 8 (1,523 Views)
0
(0)
  • Rate this reply
View profile
Solved
Dec 1, 2010 8:30:34 PM
0
(0)
Expert

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 v1.3.0.0 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.

 

Re: [U-Verse Realtime] Possible bug?

5 of 8 (1,508 Views)
Solution
0
(0)
  • Rate this reply
View profile
Dec 1, 2010 8:33:12 PM
0
(0)
Teacher
Edited by Polian on Dec 1, 2010 at 8:38:05 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:

WRN2010-12-01T21:29:45-06:00
krtlock: thread httpd (tid 342) slow wr held 'device'@0x43fc7f14 for 11.34s
ERR2010-12-01T21:29:45-06:00
krtlock: slck: httpd (tid 342) httpd (pid 320):
ERR2010-12-01T21:29:45-06:00
krtlock: [342/320] - 0: 0x409862d5

 

 

edit: I think I posted this last entry as you did yours :smileyhappy: 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.

Re: [U-Verse Realtime] Possible bug?

[ Edited ]
6 of 8 (1,507 Views)
0
(0)
  • Rate this reply
View profile
Dec 1, 2010 8:43:29 PM
0
(0)
Expert
Edited by SomeJoe7777 on Dec 1, 2010 at 8:45:24 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.

 

Re: [U-Verse Realtime] Possible bug?

[ Edited ]
7 of 8 (1,489 Views)
0
(0)
  • Rate this reply
View profile
Dec 1, 2010 9:08:40 PM
0
(0)
Teacher

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.

Re: [U-Verse Realtime] Possible bug?

8 of 8 (1,475 Views)
Share this post
Share this post