elaprince wrote:I think everyone here is waiting for non Haswell version I can safely say
Thank you for update Gordon
Well I do not think everyone. At least I don't. :)
I'd rather wait for fixed device version with "wait function" working on 2012 R2.
ASUS-H81i Plus, i3 4360, 8GB RAM, Linear PSU. USB/PCI PPA Studio V2.
Ubuntu Live USB in RAM
Soekris R2R Salas Ref D powered -> Modulus 86 -> MA Silver 8
elaprince wrote:Just to see if there is any new updates?
Thanks
need to get win 8.1 working so will do a non haswell win 8.1 build with device fix and multitrack. still think best sq might still be with fixed device.
Great news. Thank you.
PC: CPU Q8400, 8GB Ram, Windows 8.1 x64
DAC: HRT Music Streamer II+, Asus Xonar Essence ST (+ HiEnd DYI upgrades)
elaprince wrote:I think everyone here is waiting for non Haswell version I can safely say
Thank you for update Gordon
Well I do not think everyone. At least I don't. :)
I'd rather wait for fixed device version with "wait function" working on 2012 R2.
So were all the people with cpu at 25% using win 2012 r2 ? Anyone using win 8.1. Think Lekt said that the syscall was 1 higher for 2012 r2 so could try an 2012 r2 build.
Seems that the wdm driver has a queue mechanism for when it receives more IRPs than it can handle , so I'm guessing that's what is happening when the wait is failing. The driver queues the outstanding IRPs. Think the sq is still best when it is in this mode, just the system becomes unresponsive and memory use shoots up to 80 % for some reason.
Shall try queuing different amounts of IRPs with the occasional wait to keep it under control to see if we can have the best of both worlds.
Potentially this means a short burst of activity to load the 1000 IRPs then less activity for the wait which might be beneficial. Also can try bigger buffers so less user to kernel switching.
I like the idea that the IRP is already available in a queue ready for the driver to use rather relying on timing interrupts to get it from the user client.
elaprince wrote:I think everyone here is waiting for non Haswell version I can safely say
Thank you for update Gordon
Well I do not think everyone. At least I don't. :)
I'd rather wait for fixed device version with "wait function" working on 2012 R2.
So were all the people with cpu at 25% using win 2012 r2 ? Anyone using win 8.1. Think Lekt said that the syscall was 1 higher for 2012 r2 so could try an 2012 r2 build.
I believe so. I don't recall anyone not using 2012R2 reporting this issue.
sbgk wrote: Think the sq is still best when it is in this mode, just the system becomes unresponsive and memory use shoots up to 80 % for some reason.
Hi Gordon,
Please keep in mind not all R2 Server 2012 "shoot up". At least mine didn't as mentioned in my feedback before. My idea would be that the used dll of the Server versions might be different and have different behaviour? My latest testing has been based on AO1.31b8. With the update of AO to 1.31 system dll's have been updated to actual versions.
I have had experiences like that with internal changes of the R2 Server 2012 versions before. One might check that without AO if you download the latest Iso from MS as these Iso versions are always updated.
Unfortunately I have no possibility to verify that in the next days, maybe someone else could give it a try?
Thank's
Thomas
Coax tractrix horn system 2 corner subwoofer / 6 full digital amplifier D802 floating PSU 12V battery / digital XO/DRC / 2 PC floating PSU picoless battery/Mutec REF 10/2x Mutec MC3.1+ USB floating PSU 6V/FireFace UCX floating PSU 12V battery/Mutec MC-4
As a haswell owner I'd rather like longer device string in mqnplay file to be able to create my own specific version. So many improvements being discussed and I cant try any of them :/
sbgk wrote: Think the sq is still best when it is in this mode, just the system becomes unresponsive and memory use shoots up to 80 % for some reason.
Hi Gordon,
Please keep in mind not all R2 Server 2012 "shoot up". At least mine didn't as mentioned in my feedback before. My idea would be that the used dll of the Server versions might be different and have different behaviour? My latest testing has been based on AO1.31b8. With the update of AO to 1.31 system dll's have been updated to actual versions.
I have had experiences like that with internal changes of the R2 Server 2012 versions before. One might check that without AO if you download the latest Iso from MS as these Iso versions are always updated.
Unfortunately I have no possibility to verify that in the next days, maybe someone else could give it a try?
Thank's
Thomas
I have not heared of 2012R2 users whose memory has shot up, only that PCU went up to 25% of higher depending on affinity settings.
