Bugzilla – Bug 13214
Network test shows poor performance for baby wired (wireless not yet tested)
Last modified: 2009-10-05 14:33:18 UTC
Note from campfire: ****Tom W. I'm fixing some layout issue with SP "Network Test" on baby, and I notice that baby is getting much worse net performance results than jive (looking at 7.3), and this is when baby is wired. Anything above 1000 kbps give mostly yellow/red and the cpu jumps to around 100%. **** Felix, currently the network test menu item doesn't show up correctly until bug 10839 is fixed, but you can make it appear with the following patch (plus you need to be connected to an SC on startup) Index: src/squeezeplay/share/applets/SetupNetTest/SetupNetTestMeta.lua =================================================================== --- src/squeezeplay/share/applets/SetupNetTest/SetupNetTestMeta.lua (revision 6431) +++ src/squeezeplay/share/applets/SetupNetTest/SetupNetTestMeta.lua Mon Aug 03 11:14:47 CDT 2009 @@ -27,7 +27,7 @@ function registerApplet(meta) jnt:subscribe(meta) - meta.menu = meta:menuItem('appletSetupNetTest', 'hidden', meta:string('SETUPNETTEST'), function(applet, ...) applet:open(...) end, 100) + meta.menu = meta:menuItem('appletSetupNetTest', 'networkSettings', meta:string('SETUPNETTEST'), function(applet, ...) applet:open(...) end, 100) -- add the menu item to homeMenu but 'hidden', or else the playerCurrent notification method below quits happening (not sure why this is the case, but it is) -- item will be made visible by moving it to advancedSettings in the playerCurrent notification below jiveMain:addItem(meta.menu)
Richard: Any pointers where I should start to look? Thanks
I just took a wild guess with my estimate as I have no idea right now where to look or what's wrong.
At higher rates this looks to be cpu bound on baby. Were the comparisons for jive sending the test packets to jive itself or to another player? I suspect the issue is the lua processing on the test traffic which is sent over slimproto. I will have a quick look at it.
The following will minimise any processing we do on test packets at gets it to working at 2000 kpbs. This is for wireless, wired may be higher if the drives use less cpu. Anyway it still runs out of cpu and would need a new slimproto or test packet implentation to go faster. Suggest add this patch, plus restrict the test to 2000 kpbs for Squeezeplay players in the server? --- ../../../../squeezeplay/src/squeezeplay/share/jive/net/SlimProto.lua 2009-08-03 10:23:26.000000000 +0100 +++ ../share/jive/jive/net/SlimProto.lua 2009-08-15 12:15:14.000000000 +0100 @@ -452,6 +452,13 @@ -- decode opcode local opcode = string.sub(data, 1, 4) + + -- discard network test packets without processing + -- we need to minimse processing as they can arrive at a high rate + if opcode == 'test' then + return + end + log:debug("read opcode=", opcode, " #", #data) --_hexDump(opcode, data)
Why is this a P1 bug with 24 hours left? Seems like a problem that still needs to be investigated to see if it has any user impact on all network interfaces apart from strange readings in the network test.
Dean: Why did you assign this to QA? what do you want us to do in regards to this bug?
Dean - re: 24h, please see my comment #3
Its not a user impact its due to the efficiency of lua implementing slimproto as much as anything else. I've proposed a way forward - do you want this implemented (i.e. code checked in and server restricted?)
Adrian: can you apply your patch and test it out, thanks
== Auto-comment from SVN commit #7245 to the jive repo by adrian == == https://svn.slimdevices.com/jive?view=revision&revision=7245 == Bug: 13214 Description: discard network test traffic early as it causes high cpu load, update test display
Please try updated version with svn 28256 - should be able to show 100% throughput at 2000kbps
assigning to myself to test when I have a baby in front of me...
Actually its not fixed - its now showing very high system cpu load during these tests which is restricting the measurement. Has something else changed? Mem: 47040K used, 15048K free, 0K shrd, 7196K buff, 16076K cached CPU: 0% usr 66% sys 0% nic 0% idle 0% io 0% irq 33% sirq Load average: 1.45 1.55 1.09 3/65 1671 PID PPID USER STAT VSZ %MEM %CPU COMMAND 749 1 root R 26752 43% 60% /usr/bin/jive
(In reply to comment #13) > Actually its not fixed - its now showing very high system cpu load during these > tests which is restricting the measurement. Has something else changed? > > Mem: 47040K used, 15048K free, 0K shrd, 7196K buff, 16076K cached > CPU: 0% usr 66% sys 0% nic 0% idle 0% io 0% irq 33% sirq > Load average: 1.45 1.55 1.09 3/65 1671 > PID PPID USER STAT VSZ %MEM %CPU COMMAND > 749 1 root R 26752 43% 60% /usr/bin/jive Not that I know of....
So I can't profile this on the device, but looking at the application profile on the desktop, some of the highest entries are lua string handling and garbage collection. I speculate that we can improve string performance with our own string library which supports byte stream processing for protocols such as slimproto, but does not do the hashing etc of standard lua strings. I was thinking of looking at this for my rtmp implementation, on the basis that it may be of use here too. But this would be a longer term solution. Other than that the other area to look at is why the high sys load? Really need some profiling on the device for this.
It would be better to implement a 'null' decoder in SP (and maybe even ip3k), and then use the http streaming to measure the bandwidth.
Well if you can implement it in ip3k too that would be good - current code was designed around not changing the firmware. This would require a rewrite of the SC end so we can write to the socket at known instances in time rather than it being processed by the current streaming code - or we change nettest completly to just run as fast as possible which would then hook into current SC more easily.
Is this fixed by 7643 (well does it now reach 2M?)
(In reply to comment #18) > Is this fixed by 7643 (well does it now reach 2M?) Yes. Adrian, the perfhook slowdown did get put in on the 25th, after you fixed the net test issue, and a few days before you noticed it wasn't performing well again... :)
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.