Anonymous | Login | 03-04-2021 16:42 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | |||||||
0007652 | [Squeak] VM | minor | always | 07-14-11 19:47 | 01-06-14 18:18 | |||||||
Reporter | matthewf | View Status | public | |||||||||
Assigned To | lewis | |||||||||||
Priority | normal | Resolution | open | |||||||||
Status | assigned | Product Version | ||||||||||
Summary | 0007652: The idle process does not wake up when delays are scheduled, on linux | |||||||||||
Description | I have a thread that sends network messages at a constant rate. it's supposed to send at about 100 packets per second (delay of 10ms). However, it always sends at 50 packets per second unless I move the mouse around. When moving the mouse around, it sends nearer it's desired frequency. Enabling higherPerformance does not help | |||||||||||
Additional Information |
This is my VM: (standard interpreter 4.4.7 on ubuntu 11.04 linux, with a couple extra plugins for cobalt) 4.4.7-2357 #1 XShm Sun Jan 23 18:17:31 PST 2011 gcc 4.3.2 Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux plugin path: ./bin/i686-pc-linux-gnu [default: /media/Knoppix/opencobalt-1.0alpha12-squeak16.fat/bin/i686-pc-linux-gnu/] |
|||||||||||
Attached Files | ||||||||||||
|
![]() |
|
(0014155 - 524 - 548 - 548 - 548 - 548 - 548) KenCausey 07-14-11 20:45 edited on: 07-14-11 20:45 |
I could be mistaken but this seems somehow related to an issue we have at least seen on source.squeak.org and I suspect affects many Squeak websites occasionally. What we have seen is that source.squeak.org will stop responding. If one simply connects to the image via RFB (aka VNC) and wiggles the mouse the system begins responding again normally and may do so for many weeks before this comes up again. Actually it has been a while since we have seen this behavior I think, I'm not sure what changed (poor memory). |
(0014156 - 285 - 303 - 303 - 303 - 303 - 303) matthewf 07-14-11 21:13 |
I was able to work around the issue and have processes run at full speed by commenting out #interCyclePause: in WorldState >> doOneCycleFor: However, this makes squeak run at full cpu all the time. I noticed that squeak runs at full cpu anyway when the mouse is moving. not sure why |
(0014157 - 198 - 198 - 198 - 198 - 198 - 198) matthewf 07-14-11 21:21 |
If I start an infinite loop in a low priority process some other way (ui process or otherwise), my network sender process runs at full speed. I guess allowing the idle process to run causes this bug |
(0014158 - 354 - 354 - 354 - 354 - 354 - 354) matthewf 07-14-11 21:53 |
The maximum frequency the delay will run at normally is independent of the morphic event loop; the number 50fps seems to be a mere coincidence, as that is the default frequency the morphic event loop runs at. If I set the morphic event loop to wait 1 millisecond or 2000 milliseconds between runs, my delay will never wakeup more than 50 times per second |
(0014159 - 226 - 238 - 238 - 238 - 238 - 238) matthewf 07-14-11 22:09 edited on: 07-14-11 22:10 |
The delay wakeup cap seems to actually be 60fps; it sometimes wakes up as many as 58.5 times per second if the processor is idling, but no more. This makes me suspect the VM relinquishPhysicalProcessor code or the Delay code |
(0014160 - 4641 - 10584 - 10584 - 10584 - 10584 - 10584) craig 07-14-11 22:32 |
Shouldn't the relinquish-processor primitive (230) make the next delay wakeup tick the most important consideration? Something like... void relinquishPhysicalProcessor(void) { /* relinquishPhysicalProcessor */ /* the next delay wakeup time */ int nextWakeupTick = vm->getNextWakeupTick(); int now = (vm->ioMicroMSecs() & 0x1fffffff); int timeoutInMilliseconds; #ifdef UNIXISH struct timeval currentTime; struct timespec wakeupTime; #endif if (nextWakeupTick <= now) { if (nextWakeupTick == 0) /* * Timer interrupts have been disabled; wait * for as long as possible before anyone might * notice. Specifically, wait for one frame * at a typical GUI frame rate (60 Hz). */ timeoutInMilliseconds = (1000/60); else /* * The next delay wakeup time has passed and * the system should resume as soon as * possible. */ timeoutInMilliseconds = 0;} else timeoutInMilliseconds = nextWakeupTick - now; #ifdef UNIXISH pthread_mutex_lock(&activity.mutex); gettimeofday(¤tTime, NULL); wakeupTime.tv_nsec = (currentTime.tv_usec * 1000) + (timeoutInMilliseconds * 1000000); wakeupTime.tv_sec = currentTime.tv_sec + (wakeupTime.tv_nsec / 1000000000); wakeupTime.tv_nsec %= 1000000000; pthread_cond_timedwait( &activity.request, &activity.mutex, &wakeupTime); pthread_mutex_unlock(&activity.mutex); #endif vm->setInterruptCheckCounter(0);} |
(0014161 - 927 - 1035 - 1035 - 1035 - 1035 - 1035) matthewf 07-14-11 23:06 edited on: 07-14-11 23:07 |
Here is a chunk of code you can evaluate in a workspace to see how often a delay is triggering. It should be triggering about 1000 times per second, but is actually triggering 30-40 times per second on my machine when idle, or 170-180 times per second when I keep the mouse in constant motion | tally delay morph updateDelay | tally := 0. delay := Delay forMilliseconds: 1. updateDelay := Delay forMilliseconds: 1000. morph := TextMorph new openInWorld. [[tally := tally + 1. delay wait] repeat] forkAt: 44. [[morph contents: tally printString. tally := 0. updateDelay wait] repeat] forkAt: 45. (to stop the code, kill processes of priority 44, 45, and 35 in the process browser, and delete the morph) If I start a low priority infinite loop to completely starve the idle process, the delay wakes up 995-998 times per second, which is good: [[] repeat] forkAt: 35 Except that we like running at low cpu |
(0014162 - 130 - 130 - 130 - 130 - 130 - 130) craig 07-14-11 23:12 |
I tried your workspace code with a VM that uses my relinquish primitive. It's near 1000 all the time, whether I use the UI or not. |
(0014163 - 132 - 132 - 326 - 326 - 326 - 326) KenCausey 07-15-11 19:13 |
This issue is also being discussed on the vm-dev list. See http://lists.squeakfoundation.org/pipermail/vm-dev/2011-July/008811.html [^] |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
89 total queries executed. 50 unique queries executed. |