Hmm...doing a little math, if we assume that we're only checking every 
3ms, with a buffer limit of 500, we'd be able to issue at most 166,666 
signals during a given second (and that's only if the signals were 
evenly distributed in each 3 ms interval).  Is it possible that 50 http 
requests could generate that many signals?  Is it possible that we're 
falling well short of checking every 3 ms?

- Stephen

John M McIntosh wrote:

> Good morning. When I was writing the open transport socket logic and  
> doing testing on a 100mbit network where I'd get upwards of 80-90Mbit  
> saturation I discover that the original model of signaling semaphores  
> wouldn't work because my test cases uncovered the loss of semaphores.  
> This was because the original logic had a small table and it was a  
> counter and an array which wasn't thread safe, draining the array at  
> the same time an interrupt driven routine deposited a new element  
> caused interesting side-effects.
>
> The existing model uses two counters and two (what 500 entry?) tables  
> and the VM switch betweeen them to allow the interrupt driven 
> routines  to deposit new semaphores as it drains the existing table, 
> then  switchs... This seems fairly thread safe?  The number I picked 
> was  chosen as about 2 times the highest observed threshold in my 
> 100mb test  environment, say 200+ per second
>
> To have another number means building a new VM and changing that  
> constant, let's see, yes SemaphoresToSignalSize
>
> Now when do we look at the array and drain it? Well check out  
> checkForInterrupts
> how often this is called is limited by interruptChecksEveryNms (3ms)
> but just to make life more interesting I believe on windows a call is  
> forced every 1ms and usage of delays will force more activity to ensure
> Delay waits are accurate to a millisecond or so, depending on the  
> platform.  You'll need to check your platform to confirm expectations.
>
> Mmm I think you need to build a new VM if you want to expose high 
> water  marks for semaphore usage, but I don't think this is the problem.
>
> On Wednesday, November 5, 2003, at 08:20 AM, Stephen Pair wrote:
>
>> In all of the tests that I've seen of Comanche's socket serving  
>> performance, I've never seen it handle more than 50 incoming 
>> requests  per second, regardless of the CPU (if anyone has observed 
>> higher  performance, please let me know).  This makes me think that 
>> we may be  throttled by Squeak VM logic that checks for interrupts 
>> (and signals  external semaphores)...maybe, we're exeeding the size 
>> of the  semaphores to signal buffers.  Is there a way that I can play 
>> with the  interval that we check for interrupts without building a 
>> new VM?    Also, is there a way to adjust the size of the 
>> semaphoresToSignal  buffers?  And, finally, is there a way to monitor 
>> the number of  semaphores that are being marked for signaling during 
>> each cycle (to  see if we're approaching or exceeding the limit)?
>>
>> - Stephen
>>
>>
>>
>>
> -- 
> ======================================================================== 
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================== 
> ===
>
>