OvenWerks | zequence: How can I stress test lowlatency? Right now I can run jack at minimum latency (16/2) and process audio using gutarix or rakarrack with no xruns. I seem to be able to run 4 or 5 softsynths at a time as well already. Not much of a keyboard player so a sequence to run may be best. | 00:27 |
---|---|---|
zequence | OvenWerks: Use the rt-tests package | 00:30 |
zequence | DalekSec: Nope. Haven't had time to get into that yet | 00:31 |
DalekSec | Ah, alrighty-o. | 00:32 |
zequence | OvenWerks: I was going to give you a link yesterday to an example test, but had some problems and then had to go to sleep | 07:35 |
zequence | ..hang on | 07:35 |
zequence | OvenWerks: You can skip the part of building the test, and just do the command at the bottom https://wiki.ubuntu.com/UbuntuStudio/CyclicTest | 07:37 |
zequence | You get a value at the end, which on a realtime kernel is commonly below 400, down to 200 or so. | 07:38 |
zequence | Compare generic and lowlatency. Lowlatency will give you a value of several thousands, typically. I have gotten up to 1200 with lowlatency | 07:39 |
zequence | Sorry, generic will give you a value of several thousands | 07:39 |
zequence | What you can notice from the test is that -lowlatency can perform really well 90% of the time, but now and again it will spike and not be able to finish a process in the same short amount of time | 07:40 |
zequence | -rt, however, should perform a lot tighter, and not have these random spikes | 07:41 |
zequence | OvenWerks: Ah, re: issuing the command at the bottom. First, of course, you need to install the package rt-tests, where you will find cyclictest | 07:42 |
zequence | hmm, I think rt-tests builds a module for the kernel now. | 07:43 |
zequence | OvenWerks: Ah, right. You want to do stuff during the test, preferably using both graphics and other stuff. You can unpack a big file, while watching flash video - like one or several youtube videos | 07:46 |
zequence | Haven't looked at rt-tests for a long time, but, I think it comes with some stressing tools as well | 08:01 |
zequence | Perhaps the tool hackbench, which is a part of the suite rt-tests | 08:03 |
zequence | OvenWerks: The value I'm talking about is "highest". I don't recall what they represent, but it's the time it takes for a process complete, just to clarify. There's a average value as well | 09:57 |
Rosco2 | Newbie question: I am member of Ubuntu Studio Bugs. Description in Launchpad says team is subscribed to many bugs. I don't actually get too many emails. | 10:48 |
Rosco2 | I know it is possible to subscribe UbuntuStudioBugs or USDevel teams to a bug if you think they should be aware and follow an issue. | 10:49 |
Rosco2 | Originally assumed that USBugs would be subscribed to/owner of packages/meta packages and automatically get all bug traffic? | 10:51 |
Rosco2 | Are my assumptions correct? | 10:51 |
zequence | Rosco2: Unfortunately that team is not subscribed to all bugs that it needs to be aware of | 10:53 |
zequence | Rosco2: I've started that work some time ago. I believe the group should automatically get all bug reports for those projects - have you found that it doesn't? | 10:54 |
zequence | Or, packages, rather | 10:54 |
zequence | But, projects too, I suppose, if you subscribe to them | 10:54 |
Rosco2 | I have received some emails. But based on the popularity of some packages - I thought they would be more high traffic. | 10:55 |
zequence | Rosco2: If you want to help out, you are welcome to make that team more functional | 10:55 |
zequence | maybe it's just rare that people report bugs? You could compare by looking at the bugs for a specific package, and see if you got all mail about it | 10:56 |
Rosco2 | Yeah - sure. Triaging hardware related stuff is tricky for me. | 10:56 |
Rosco2 | But I have learn't a few of the tricks that the Bug Squad use. | 10:57 |
Rosco2 | To get people involved & triaging in a consistent way I mean | 10:58 |
Rosco2 | Will check my mails against what packages have had bugs submitted recently | 11:06 |
Rosco2 | zequence: My inbox contained lots of bug reports from ubuntustudio-met, -live, linux-rt, ubuntustudio, -live-setting etc. | 13:53 |
Rosco2 | zequence: There was a blender bug, and when I clicked around on other blender bugs, every time USBugs were on the "May receive notifications" section. | 13:55 |
Rosco2 | OTOH, when I went to bug page for audacity, there were not many bugs where USBugs were subscribed. | 13:56 |
Rosco2 | Maybe it is a packages/meta packages allocation/categorisation thing? | 13:58 |
=== Unismurfhedgehog is now known as SonikkuAmerica | ||
Rosco2 | OK, now I understand. US-Devel team are subscribed to these packages: https://bugs.launchpad.net/~ubuntustudio-dev/+packagebugs | 14:13 |
Rosco2 | US-Bugs team are subscribed to a smaller set of individual packages: https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs | 14:14 |
Rosco2 | We could increase the list for US-Bugs to other important packages, but maybe there would be too much noise? | 14:15 |
Rosco2 | At least that fits with what emails I received. So it is not a launchpad/email problem. | 14:17 |
zequence | Rosco2: The whole point of ubuntustudio-bugs team is to receive all relevant bugs, so it's fine if they receive everything | 16:08 |
zequence | Rosco2: ubuntustudio-dev really only needs to receive bugs from projects that team is a part of | 16:08 |
zequence | By *everything* I mean anything that is multimedia related, and on the Ubuntu Studio ISO | 16:09 |
OvenWerks | zequence: how much stress to test with? If I run cpu hogs my max goes way up, but they are running the cpus at 100% too. which is not at all normal for audio work. | 16:37 |
OvenWerks | With all 4 cpus at 100% my max is in the 4500 range. | 16:38 |
OvenWerks | with only 1 cpu hog pulling one cpu to 100% the max goes up to 7500 which seems odd. | 16:39 |
OvenWerks | Running a video and a sound generator gives max of 15 to 25. | 16:45 |
zequence | OvenWerks: What is most interesting is to see the random xrun, IMO | 16:45 |
OvenWerks | I will have to install the two other kernels to test more. | 16:45 |
zequence | OvenWerks: You can have no xruns for 2h, until you move the mouse, and something graphical happens | 16:45 |
OvenWerks | No xruns at all so far | 16:45 |
OvenWerks | Jack has been running for 2 or 3 days now | 16:46 |
zequence | OvenWerks: One classic way to cause all cores to work is compiling something big - making sure in the compilation command that all cores are used | 16:46 |
zequence | Like, linux | 16:47 |
OvenWerks | My default setup is now that jack starts with session and paulse goes through that. | 16:47 |
OvenWerks | I was running "stress" | 16:47 |
zequence | OvenWerks: I understand you took special care in making sure all your HW components are tuned right? | 16:48 |
OvenWerks | Yes. | 16:48 |
zequence | OvenWerks: Would be interesting to see if you configured all of that "wrong" | 16:48 |
OvenWerks | Some things I can't do like add hyperthreading | 16:48 |
zequence | OvenWerks: If that has a great impact, we should absolutely document it and make it available to our users | 16:48 |
OvenWerks | I am also running performance not ondemand which on this machine gives xruns up till about 10ms | 16:50 |
OvenWerks | Interestingly, ondemand creates more heat than performance at high cpu usage | 16:50 |
OvenWerks | It seems that running different cores at different speeds creates more heat. | 16:51 |
OvenWerks | anyway it is family time for the day. This is a long weekend for us. | 16:58 |
zequence | OvenWerks: See you later Oven | 18:25 |
zequence | Len, I mean :P | 18:25 |
zequence | I made Ross admin of ubuntustudio-bugs team, as he's to help us with making it subscribe to relevant bugs | 18:25 |
Rosco2 | Slowly subscribing to packages in ubuntustudio-meta! | 20:29 |
Rosco2 | Check progress here: https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs | 20:30 |
Rosco2 | It gives good stats on the bugs - there are a few to work on :-) | 20:30 |
zequence | Rosco2: I wonder if it would be a good idea to recommend debian-multimedia devs to become members of that group. Our versions of packages aren't always the same as in Debian, since we sync from their development release | 21:49 |
zequence | In either case, when a bug has been identified as valid, one needs to check if the bug is also affecting whatever Debian version of the package, and report it also in Debian | 21:50 |
zequence | Once there is a fix, we either sync from Debian, or do a patch. For our development release, we should always sync, unless it's really late in the cycle. For stable release it might be better to patch. | 21:52 |
zequence | And the patch should only fix the bug, not update to a newer release, or we sync. But, I suppose you know this already. | 21:52 |
zequence | I'm probably not making perfect sense this late on a saturday evening :) | 21:53 |
zequence | Yep, there are a few bugs there | 21:55 |
Rosco2 | I suppose I could let them know on debian-multimedia mailing list and ask if anyone wants to join | 22:06 |
Rosco2 | You are right, that perhaps we should pinch some stuff from Ubuntu Bug Squad, and tailor it to our needs and specific deb-multi upstream | 22:08 |
Rosco2 | And what you say about when to patch, when to sync etc. could also be added to the wiki | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!