asking community to try a workspace - SstTcpSocketPair / SstTcpSocketSieve ECONNREFUSED

Hi Wayne
This are my times on Win7/64 with VA 8.5.2

b done in 702 milliseconds.

a done in 702 milliseconds.

d done in 702 milliseconds.
c done in 717 milliseconds.


El jueves, 24 de enero de 2013 14:46:15 UTC-3, Wayne Johnston escribió:

I’d like to ask people with Windows 7 machines to try this workspace.  If SstTcpSocketPair is undefined then load the SST-Base feature.

| block |

block := [ |theMilliseconds |

theMilliseconds := Time millisecondsToRun: [

500 timesRepeat: [ | pair |

pair := SstTcpSocketPair new.

pair isSciError

ifTrue: [Transcript show: ' ', Processor activeProcess processName, '-', pair printString]

ifFalse: [pair close] 

].

].

Transcript show: Character lf asString, Processor activeProcess processName, ' done in ', theMilliseconds printString, ' milliseconds.'. 

].

block forkNamed: 'a'.

block forkNamed: 'b'.

block forkNamed: 'c'.

block forkNamed: 'd'.

If you see some failures, please post your results as well as your OS (including whether it’s a VM or a real computer).

For my teammates with Windows 7 laptops, we are seeing those processes take a minute or two to complete, as opposed to other environments (Windows XP, or even Windows 7 VMs) where they take maybe 3-5 seconds.  But that delay doesn’t bother me.  What bothers me is that we are seeing failures.  On Windows 7 laptops we see one or more ECONNREFUSED failures, while on Windows XP laptops we see EADDRINUSE failures.  It seems the failures only occur when we have multiple of the above processes running, implying a concurrency problem (in VA or Windows, we don’t know).  Indeed, putting in a Semaphore to avoid concurrent callouts to this avoids the problem:

<c: int32 essci40:SciConnect int32 pointer int32 struct>

By the way with benchmarking I see (without the Semaphore) that callout is where the delay is for us on Windows 7.

I am asking the community try this because Instantiations (case INST50159) couldn’t reproduce the problem.  So it is quite believable that the cause is something on our corporate-issued laptops that my teammates and I have.  But if someone else out there can reproduce the failures, that would imply Instantiations should try to fix it.  Since the failure is fairly rare, maybe a simple retry would work.  I could put a retry in myself, but the question is whether Instantiations should do it.  I’ve seen the slowness/failures in VA 8.0.0 and 6.0.2 and 5.5.2 on my Windows 7 laptop.

I have seen that sometimes I’ve had to run the workspace a couple times before I hit an error.  But if you run the above workspace enough times fast enough, there will be many failures because of the lack of ephemeral (“random high-numbered”) ports.  It’s fun to watch things in TCPView, which shows grabbing and releasing of the ports as we cycle through them.  Actually the ports stay in the TIME_WAIT state for a while once we are done with them.  So avoid running the workspace repeatedly fast enough to run out of ports.  

The starting point for this investigation was one of my teammates seeing ‘SstTcpSocketPair new’ fail during our server startup.  This happened just once, and I would hope it’s rare enough (or environmental enough) such that none of our customers will see it.  Our server doesn’t run multiple ‘SstTcpSocketPair new’ in parallel -  but we could have multiple of our servers starting up at the same time.  Or since the original failure was just with one server, my theory is that there was something concurrent happening on the machine.

Thank you.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To post to this group, send email to [hidden email].

Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Windows XP Professional x86 Laptop. VAST 8.5.2

VA Smalltalk V8.5.2; Image: 8.5.2 [232]
VM Timestamp: 4.0,(NC) 8/7/2012 (84)
(C) Copyright Instantiations 1994, 2012.  All rights reserved.
(C) Copyright International Business Machines Corp. 1994, 2006.  All rights reserved.
a done in 2609 milliseconds.
c done in 2594 milliseconds. b-EADDRINUSE (10048): Address already in use
 b-EADDRINUSE (10048): Address already in use
 b-EADDRINUSE (10048): Address already in use
 d-EADDRINUSE (10048): Address already in use

b done in 2610 milliseconds.
d done in 2610 milliseconds.

BUT!! If I run it again right afterwards...

It produces tons of errors.

The more I run it, the more errors I get.

(File attached, its a big log)

On Fri, Jan 25, 2013 at 3:18 AM, Leo O. <[hidden email]> wrote:

Hi Wayne
This are my times on Win7/64 with VA 8.5.2

b done in 702 milliseconds.

a done in 702 milliseconds.

d done in 702 milliseconds.
c done in 717 milliseconds.


El jueves, 24 de enero de 2013 14:46:15 UTC-3, Wayne Johnston escribió:

I’d like to ask people with Windows 7 machines to try this workspace.  If SstTcpSocketPair is undefined then load the SST-Base feature.

| block |

block := [ |theMilliseconds |

theMilliseconds := Time millisecondsToRun: [

500 timesRepeat: [ | pair |

pair := SstTcpSocketPair new.

pair isSciError

ifTrue: [Transcript show: ' ', Processor activeProcess processName, '-', pair printString]

ifFalse: [pair close] 

].

].

Transcript show: Character lf asString, Processor activeProcess processName, ' done in ', theMilliseconds printString, ' milliseconds.'. 

].

block forkNamed: 'a'.

block forkNamed: 'b'.

block forkNamed: 'c'.

block forkNamed: 'd'.

If you see some failures, please post your results as well as your OS (including whether it’s a VM or a real computer).

For my teammates with Windows 7 laptops, we are seeing those processes take a minute or two to complete, as opposed to other environments (Windows XP, or even Windows 7 VMs) where they take maybe 3-5 seconds.  But that delay doesn’t bother me.  What bothers me is that we are seeing failures.  On Windows 7 laptops we see one or more ECONNREFUSED failures, while on Windows XP laptops we see EADDRINUSE failures.  It seems the failures only occur when we have multiple of the above processes running, implying a concurrency problem (in VA or Windows, we don’t know).  Indeed, putting in a Semaphore to avoid concurrent callouts to this avoids the problem:

<c: int32 essci40:SciConnect int32 pointer int32 struct>

By the way with benchmarking I see (without the Semaphore) that callout is where the delay is for us on Windows 7.

I am asking the community try this because Instantiations (case INST50159) couldn’t reproduce the problem.  So it is quite believable that the cause is something on our corporate-issued laptops that my teammates and I have.  But if someone else out there can reproduce the failures, that would imply Instantiations should try to fix it.  Since the failure is fairly rare, maybe a simple retry would work.  I could put a retry in myself, but the question is whether Instantiations should do it.  I’ve seen the slowness/failures in VA 8.0.0 and 6.0.2 and 5.5.2 on my Windows 7 laptop.

I have seen that sometimes I’ve had to run the workspace a couple times before I hit an error.  But if you run the above workspace enough times fast enough, there will be many failures because of the lack of ephemeral (“random high-numbered”) ports.  It’s fun to watch things in TCPView, which shows grabbing and releasing of the ports as we cycle through them.  Actually the ports stay in the TIME_WAIT state for a while once we are done with them.  So avoid running the workspace repeatedly fast enough to run out of ports.  

The starting point for this investigation was one of my teammates seeing ‘SstTcpSocketPair new’ fail during our server startup.  This happened just once, and I would hope it’s rare enough (or environmental enough) such that none of our customers will see it.  Our server doesn’t run multiple ‘SstTcpSocketPair new’ in parallel -  but we could have multiple of our servers starting up at the same time.  Or since the original failure was just with one server, my theory is that there was something concurrent happening on the machine.

Thank you.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To post to this group, send email to [hidden email].

Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Windows 7 Ultimate x64
VA Smalltalk V8.6


a done in 1125 milliseconds.
c done in 1125 milliseconds.
b done in 1141 milliseconds.
d done in 1141 milliseconds.


b done in 1078 milliseconds.
c done in 1078 milliseconds.
a done in 1078 milliseconds.
d done in 1078 milliseconds.


d done in 1062 milliseconds.
c done in 1062 milliseconds.
b done in 1062 milliseconds.
a done in 1078 milliseconds.


c done in 968 milliseconds.
b done in 984 milliseconds.
a done in 984 milliseconds.
d done in 1187 milliseconds.

On Fri, Jan 25, 2013 at 10:58 AM, Dusty <[hidden email]> wrote:

Windows XP Professional x86 Laptop. VAST 8.5.2

VA Smalltalk V8.5.2; Image: 8.5.2 [232]
VM Timestamp: 4.0,(NC) 8/7/2012 (84)
(C) Copyright Instantiations 1994, 2012.  All rights reserved.
(C) Copyright International Business Machines Corp. 1994, 2006.  All rights reserved.
a done in 2609 milliseconds.
c done in 2594 milliseconds. b-EADDRINUSE (10048): Address already in use
 b-EADDRINUSE (10048): Address already in use
 b-EADDRINUSE (10048): Address already in use
 d-EADDRINUSE (10048): Address already in use

b done in 2610 milliseconds.
d done in 2610 milliseconds.

BUT!! If I run it again right afterwards...

It produces tons of errors.

The more I run it, the more errors I get.

(File attached, its a big log)

On Fri, Jan 25, 2013 at 3:18 AM, Leo O. <[hidden email]> wrote:

Hi Wayne
This are my times on Win7/64 with VA 8.5.2

b done in 702 milliseconds.

a done in 702 milliseconds.

d done in 702 milliseconds.
c done in 717 milliseconds.


El jueves, 24 de enero de 2013 14:46:15 UTC-3, Wayne Johnston escribió:

I’d like to ask people with Windows 7 machines to try this workspace.  If SstTcpSocketPair is undefined then load the SST-Base feature.

| block |

block := [ |theMilliseconds |

theMilliseconds := Time millisecondsToRun: [

500 timesRepeat: [ | pair |

pair := SstTcpSocketPair new.

pair isSciError

ifTrue: [Transcript show: ' ', Processor activeProcess processName, '-', pair printString]

ifFalse: [pair close] 

].

].

Transcript show: Character lf asString, Processor activeProcess processName, ' done in ', theMilliseconds printString, ' milliseconds.'. 

].

block forkNamed: 'a'.

block forkNamed: 'b'.

block forkNamed: 'c'.

block forkNamed: 'd'.

If you see some failures, please post your results as well as your OS (including whether it’s a VM or a real computer).

For my teammates with Windows 7 laptops, we are seeing those processes take a minute or two to complete, as opposed to other environments (Windows XP, or even Windows 7 VMs) where they take maybe 3-5 seconds.  But that delay doesn’t bother me.  What bothers me is that we are seeing failures.  On Windows 7 laptops we see one or more ECONNREFUSED failures, while on Windows XP laptops we see EADDRINUSE failures.  It seems the failures only occur when we have multiple of the above processes running, implying a concurrency problem (in VA or Windows, we don’t know).  Indeed, putting in a Semaphore to avoid concurrent callouts to this avoids the problem:

<c: int32 essci40:SciConnect int32 pointer int32 struct>

By the way with benchmarking I see (without the Semaphore) that callout is where the delay is for us on Windows 7.

I am asking the community try this because Instantiations (case INST50159) couldn’t reproduce the problem.  So it is quite believable that the cause is something on our corporate-issued laptops that my teammates and I have.  But if someone else out there can reproduce the failures, that would imply Instantiations should try to fix it.  Since the failure is fairly rare, maybe a simple retry would work.  I could put a retry in myself, but the question is whether Instantiations should do it.  I’ve seen the slowness/failures in VA 8.0.0 and 6.0.2 and 5.5.2 on my Windows 7 laptop.

I have seen that sometimes I’ve had to run the workspace a couple times before I hit an error.  But if you run the above workspace enough times fast enough, there will be many failures because of the lack of ephemeral (“random high-numbered”) ports.  It’s fun to watch things in TCPView, which shows grabbing and releasing of the ports as we cycle through them.  Actually the ports stay in the TIME_WAIT state for a while once we are done with them.  So avoid running the workspace repeatedly fast enough to run out of ports.  

The starting point for this investigation was one of my teammates seeing ‘SstTcpSocketPair new’ fail during our server startup.  This happened just once, and I would hope it’s rare enough (or environmental enough) such that none of our customers will see it.  Our server doesn’t run multiple ‘SstTcpSocketPair new’ in parallel -  but we could have multiple of our servers starting up at the same time.  Or since the original failure was just with one server, my theory is that there was something concurrent happening on the machine.

Thank you.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

To post to this group, send email to [hidden email].

Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dusty - thanks for your results.  http://en.wikipedia.org/wiki/Ephemeral_port   Yeah since XP has a much smaller range of ephemeral ports, running the workspace more than once without much delay between will result in errors.  Sorry I didn't remind myself of that narrow range until now.  Anyway these errors and your other results are still 'more of the same' - thanks - hoping someone reproduces the more rare error...

On Friday, January 25, 2013 3:58:08 AM UTC-5, Dusty wrote:

Windows XP Professional x86 Laptop. VAST 8.5.2

...

BUT!! If I run it again right afterwards...

It produces tons of errors.

The more I run it, the more errors I get.

(File attached, its a big log)

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.

To post to this group, send email to [hidden email].

To unsubscribe from this group, send email to [hidden email].

Visit this group at http://groups.google.com/group/va-smalltalk?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.