Socket performance

John M McIntosh johnmci at smalltalkconsulting.com
Wed Nov 5 18:27:20 UTC 2003


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
======================================================================== 
===




More information about the Squeak-dev mailing list