[00:27] <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:30] <zequence> OvenWerks: Use the rt-tests package
[00:31] <zequence> DalekSec: Nope. Haven't had time to get into that yet
[00:32] <DalekSec> Ah, alrighty-o.
[07:35] <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:37] <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:38] <zequence> You get a value at the end, which on a realtime kernel is commonly below 400, down to 200 or so. 
[07:39] <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:40] <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:41] <zequence> -rt, however, should perform a lot tighter, and not have these random spikes
[07:42] <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:43] <zequence> hmm, I think rt-tests builds a module for the kernel now.
[07:46] <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
[08:01] <zequence> Haven't looked at rt-tests for a long time, but, I think it comes with some stressing tools as well
[08:03] <zequence> Perhaps the tool hackbench, which is a part of the suite rt-tests
[09:57] <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
[10:48] <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:49] <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:51] <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:53] <zequence> Rosco2: Unfortunately that team is not subscribed to all bugs that it needs to be aware of
[10:54] <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:55] <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:56] <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:57] <Rosco2> But I have learn't a few of the tricks that the Bug Squad use.
[10:58] <Rosco2> To get people involved & triaging in a consistent way I mean
[11:06] <Rosco2> Will check my mails against what packages have had bugs submitted recently
[13:53] <Rosco2> zequence: My inbox contained lots of bug reports from ubuntustudio-met, -live, linux-rt, ubuntustudio, -live-setting etc.
[13:55] <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:56] <Rosco2> OTOH, when I went to bug page for audacity, there were not many bugs where USBugs were subscribed.
[13:58] <Rosco2> Maybe it is a packages/meta packages allocation/categorisation thing? 
=== Unismurfhedgehog is now known as SonikkuAmerica
[14:13] <Rosco2> OK, now I understand. US-Devel team are subscribed to these packages: https://bugs.launchpad.net/~ubuntustudio-dev/+packagebugs
[14:14] <Rosco2> US-Bugs team are subscribed to a smaller set of individual packages: https://bugs.launchpad.net/~ubuntustudio-bugs/+packagebugs
[14:15] <Rosco2> We could increase the list for US-Bugs to other important packages, but maybe there would be too much noise?
[14:17] <Rosco2> At least that fits with what emails I received. So it is not a launchpad/email problem.
[16:08] <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:09] <zequence> By *everything* I mean anything that is multimedia related, and on the Ubuntu Studio ISO
[16:37] <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:38] <OvenWerks> With all 4 cpus at 100% my max is in the 4500 range.
[16:39] <OvenWerks> with only 1 cpu hog pulling one cpu to 100% the max goes up to 7500 which seems odd.
[16:45] <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:46] <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:47] <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:48] <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:50] <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:51] <OvenWerks> It seems that running different cores at different speeds creates more heat.
[16:58] <OvenWerks> anyway it is family time for the day. This is a long weekend for us.
[18:25] <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
[20:29] <Rosco2> Slowly subscribing to packages in ubuntustudio-meta!
[20:30] <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 :-)
[21:49] <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:50] <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:52] <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:53] <zequence> I'm probably not making perfect sense this late on a saturday evening :)
[21:55] <zequence> Yep, there are a few bugs there
[22:06] <Rosco2> I suppose I could let them know on debian-multimedia mailing list and ask if anyone wants to join
[22:08] <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:10] <Rosco2> And what you say about when to patch, when to sync etc. could also be added to the wiki