Re: Socket Listener Delay Issue -- MIDRANGE-L

Ah so Kimmel is a Raspberry Pi guy while I prefer Arduino. But lets not start a political war here. :-)

Second, I didn't see this thread initially since it was started by replying to another thread so it has stacked up under an FTP heading. You should ALWAYS Start a NEW thread with a NEW email, just sayin.....

In the past I used to be an RPG programmer. Some time back Susan Ganter declared I was down to MQC and since then I program everything IN CL. And I'm now one of the Hardware guys Dan refers too. I also teach work management.

So you're hitting 20 seconds and timing out. Even for a non-real time system 20 seconds is 'FOR-EV-ER'. I have dealt with this all the way back to the double digit cpw days.

You have taken a couple of steps in the right direction.
- Lowering the job priority number to increase it's priority is good.
- The Purge *NO is mostly not used at all any more but a nice try.

To truly keep the thing in memory you'll want to create a private memory pool for these jobs to run in. That is use the CHGSBSD with the POOLS parameter set like POOLS((3 1024 20)) to create pool 3 with 1M (yes MB, you may want more...) of memory and an activity level of 20.

Then you'll need to route those jobs into that memory pool AND NOTHING ELSE! This tactic will assure those jobs are always in memory. Your higher priority will put them near the top of the queue for CPU so two things have been solved.

What is the activity level in the pool? does WRKSYSSTS (F21 Advanced) show any "Wait-Inel" or "Act-Inel" transitions? If so that's very bad in this environment. You'll need a higher activity level in the pool.

A lot more needs to be known for sure. One is the network, is it solid? Are there any retries happening? Can you PING the devices with a rock solid (NO LOSS) ping in low double digit response times? Any packet loss will cause retransmits which can clobber response times. You say the connections are appearing in the comm trace so this may be OK, just askin.

What does the work management environment look like? Is the system heavily busy? Are there a large number of Faults? Are the disks busy? Doesn't sound like a lock issue but programs such as these need to be written so they do not need to wait for locks on data.

You say you're on a 400 but on 7.1 and that's impossible. Last release supported on AS/400 was 5.3 so you could be on a POWER5, 6, or 7 server.

My gut feel here is that this system may be overcommitted in some way.

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 8/7/2013 8:10 PM, Rich Marion wrote:

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