http://qs321.pair.com?node_id=1214771


in reply to Waiting for Device::Serialport

I do something similar but its a pic 16f877 i read from that polls Dallas One-wire 18s20 temp sensors. i use the following

$ob->read_char_time(5); # avg time between read char $ob->read_const_time(500); # timeout after 500 milliseconds = +0.5 seconds
I also am looking for complete lines so i use
my $ob = tie (*FH, 'Device::SerialPort', $cfgfile) || die "Can't tie: $!\n"; ## TIEHANDLE ##
and to read in all available lines i use
@gotits=<FH> ;
This seems to work well for me, but i can get a bunch of lines all at once for while i too only cycle every 15 seconds a cycle reads about 50 18s20 sensors 6 at a time and there may not be much time between the lines for each sensor.

One thing that may be affecting you is that

$timestamp = uts_to_iso(time());
runs even if you do not want to insert the lines.

Another thing i noticed is repeated calls to dt(). saying

my $dtdate=dt('date'); my $dttime=dt('time');
and then using the variables in the execute may speed things up.

and a last observation is that each insert cycle you run the $dbh->prepare($q); pulling these out of the while loop such that

$q = "insert into weather_data values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? +, ?, ?, ?, ?, ?, ?)"; my $sth = $dbh->prepare($q);
is only run once, nd the loop code just uses $sth->execute(...); may speed things up a whole lot.

Replies are listed 'Best First'.
Re^2: Waiting for Device::Serialport
by wjw (Priest) on May 17, 2018 at 19:10 UTC

    Good advice. I will incorporate those suggestions. Thank you!

    UPDATE: Thanks again for the feedback! I did run through to check on those things you noticed. As IFAIK, the repeated statements all only happen once the $dev->lookfor() completes. That said, looking again made me realize that the sleep(1) which I ignored even after looking at how sleep worked( could not determine if it reduced allocated resourced on the system or not), could be changed to 14 seconds as long as the timeout for reading character was increased a bit. I also moved all the processing of getting things into the DB into its own sub. The result is that the increase in sleep time reduced cpu system resources from the aforementioned 1.27 down to less between .23 to .37 on a 1 minute average and 0.4 on a 10 minute average, and that is with htop running and two ssh sessions going. So thanks again! /huck for taking the time!

    Update 1: Figured I would repost the code that I ended up here for posterity sake, and maybe helpful to someone else...

    ...the majority is always wrong, and always the last to know about it...

    A solution is nothing more than a clearly stated problem...