Dan,
Wow.
You described the issue perfectly. The listener is set to Purge *No so it
should not be swapped out. We tried setting the RUNPTY to 15 today (from
20) and still have the same issue. Priority 20 is all the interactive
sessions.
ProRace... is my home email account. I provide free timing services to
local events as a hobby. Well, they cover the cost of the RFID tags. I use
ALIEN technologies ALR9900 readers at the finish line to record the times of
the runners and wrote my own Visual Basic socket programs to download from
the chip reader the times it recorded.
The issue I described concerning the delay is with the iSeries at my full
time real job (not timing). Our warehouse people wear voice operated units
that sends information to the 400 across the network as they pick the
orders. This delay is causing their devices to timeout and resend data. I
fixed the processing programs to ignore the duplicated data, but would still
like the delay to be fixed. It does cause other issues with other
transaction sets.
It sounds like, I am going to have to expect these socket delays and ensure
my programs handle the repercussions it creates appropriately.
Or possibly, contact the vendor of the remote devices and have them lengthen
their timeout to 20 seconds.
Or Both?
Thanks again
Rich Marion
PS. If you ever come to Boise for an event, be sure to track me down. I'll
be involved in some capacity.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Wednesday, August 07, 2013 9:56 AM
To: Midrange Systems Technical Discussion
Subject: RE: Socket Listener Delay Issue
I believe the hardware and OS are doing what they're designed to do.
IBMi and Power Systems are designed to be a multiple user environment and do
not facilitate quick response to what would be interrupts on an Intel
architecture. Events like a socket connection are handled within a priority
structure that guarantees delivery of the event, but does not guarantee
"real time" delivery. Events are queued and handled according to a priority
structure that guarantees lower priority events will not be starved. Highest
priority is usually given to memory fault recovery IO events. So if it
happens that the disk drive has just recovered a segment requested by memory
management at the same time your socket connection event happens, that data
transfer to memory is going to be handled first while the socket IO event is
queued. Fifteen seconds seems a rather long time, but not out of bounds.
Could be your listener program is swapped out of memory in the interim.
IBMi is not a real-time system. If you need real-time, configure a dedicated
Linux box to monitor and let it write to disk files on IBMi if needed, but
be aware those writes will be queued, too. I'm currently enamored of using
Raspberry PI for such tasks. $35.00 and free software. Linux is not purely
"real-time" either, but you can configure a simple machine with very little
else to get in the way of a fairly deterministic response.
The hardware guys on this forum might be able to help you configure an IBMi
structured to be more responsive to your particular needs. Maybe they'll
comment.
It appears from your email address (..@ProRaceTiming.com) that you're
involved with timing races. I participate often in timed events and would
hate to give up 15 seconds because a machine didn't respond. In fact, I'd be
really pissed off. I expect my marathon time to be to the nearest hundredth
of a second. Just because of this hobby, I've studied real-time machines a
bit. IBMi is not the right hardware. Far better to get a time from the time
clock before and put that time in the IP packet to the IBMi rather than
relying on IBMi's response to an IP packet received event for time. Using
the IBMi for recording the time created by the clock eliminates the need for
reliance on immediate event handling.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Rich Marion
Sent: Monday, August 05, 2013 10:18 PM
To: 'Midrange Systems Technical Discussion'
Subject: Socket Listener Delay Issue
All,
I have encountered a little intermittent problem with a program that is
monitoring a port for any incoming connections. It appears that it does
not get notified in a timely manner, sometimes, when there is a
connection request.
I set up a listen socket descriptor, then bind to the port, then set
listen with a parm of 100.
I have it log to a file the timestamp when a connection is received. I
accept the connection to an accept socket descriptor, and then spawn
off another job passing the accepted descriptor to the new job. Each
incoming
request has its own spawned job to handle the communications. The
subsystem and jobqs are set to *NoMax.
My listener program logs every step to a log file with the time stamp
it happens.
Periodically, a network trace of the traffic will show the
communications between the remote device and the 400 NIC, but the
program will not know of
its existence until after a delay. Most of the time it processes the
request within a few micro seconds from when the remote device
initiates the connection. But every so often, the 400 NIC will not
inform my listener program of the incoming transmission for up to 15
seconds.
I know for a fact the delay is between the 400 NIC and my listener
program.
Network traces and my log files have proved this beyond any doubt.
During that delay, my listener program does continue accept and
process other requests. It has plenty of "Spare" time to handle the
delayed request.
When it decides to have a delay, it affects multiple incoming requests.
(Each request is from a separate device.) We are at V7. Can anyone
point me in a direction to go or to a forum?
Thanks
Rich M.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6558 - Release Date: 08/07/13
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6558 - Release Date: 08/07/13
midrange.com
