The system timer (TimerResolution) has nothing to do with USB host controller interrupts. You could run the timer resolution at 15.6ms and the USB interrupts would still be serviced as usual at 8k.
The system timer value is responsible for scheduling, if you constantly swap threads out then there's extra overhead with context switching and cache pollution.
Some programs too.
schizobeyondpills wrote: ↑29 Oct 2020, 10:07
yeah but u forgot the biggest two factors of power dissipation, scaling of frequency and size of both transistors/IC in nanometers, COMBINED.
We are talking about frequency scaling at the same voltage and ambient temperature. While smaller transistors can have higher power densities they usually are more power efficient but this doesn't matter. The devices quoted at 40C ambient are spec'd to work at that temperature.
schizobeyondpills wrote: ↑29 Oct 2020, 10:07
>This is the system timer and operates from around 0.5ms to 15.6ms, it is not windows time.
it is literally the source of time within the whole OS.
The system’s clock interval timer is probably the most important device on a Windows machine, as evidenced by its high IRQL value (CLOCK_LEVEL) and due to the critical nature of the work it is responsible for. Without this interrupt, Windows would lose track of time, causing erroneous results in calculations of uptime and clock time—and worse, causing timers not to expire anymore and threads never to lose their quantum anymore. Windows would also not be a preemptive operating system, and unless the current running thread yielded the CPU, critical background tasks and scheduling could never occur on a given processor.
^ from Windows Internals. try again please
No problem with the WI quote but windows time itself is typically the value loaded at startup offset by QPC count. That time may be updated via NTP if enabled and a network connection available which will then depending on the difference gradually or instantly update the time which is why it's not so good for measuring performance. QPC is called a performance counter for a reason although personally I prefer RDTSC(P). Does Windows still update a leap second in 2 seconds?
schizobeyondpills wrote: ↑29 Oct 2020, 10:07
also,please, PLEASE, stop mixing up timers and clock. its a big difference, timers are events at certain periodic intervals, clock is the source of time, tyvm.
Timers and counters!
@howiec
Didn't think about looking for an Asmedia datasheet, the similarities were enough to go by. I have the older 1142 and use microsofts driver on W10. Needed to have a device connected or the driver would disable memory space so no BAR1 data in that case. BAR values are not usually hard coded so lets just say BAR1 instead of giving it a value. At BAR1+18h is the runtime register offset which for me was 0x1000. It has 8 interrupters which are located at BAR1+0x1000+0x24, BAR1+0x1000+0x44, BAR1+0x1000+0x64... up to BAR1+0x1000+0x104. Value(s) set by the driver is/are 0xc8 but appears based on 200ns counts, not 250ns so 0xc8 would be 200ns x 200 = 40us. If using legacy interrupt then the driver just programs/uses the first interrupter, if MSI mode then all interrupts are programmed and more than one interrupter can be used. Yes, it works if modified. If you are still having trouble maybe you would post what you get for Asmedia PCI registers, BAR1 memory and runtime memory.
EDIT: Missed a / and could not fix it until after post approved. Sorry for the mess it caused. Unfortunately I have a habit of posting then editing if necessary, guess I need to remember the preview option in future :/