ticksize is being set in sysinit with “ticksize -e 100000”. After startup a
check on ticksize shows it as 0.5s. The machine this is running on will
support a ticksize of 0.1s. Why is the sysinit setting being overridden?
Maybe a program is changing it. Run ticksize there and there in the
sysinit, you’ll know at what point the ticksize was change and by who.
“Gord Sipko” <mountkidd@shaw.ca> wrote in message
news:cdm4fa$k9h$1@inn.qnx.com…
ticksize is being set in sysinit with “ticksize -e 100000”. After startup
a
check on ticksize shows it as 0.5s. The machine this is running on will
support a ticksize of 0.1s. Why is the sysinit setting being overridden?
There isn’t anything running but the OS when I’ve checked it!
“Mario Charest” <darkmatter@intothevoid.land> wrote in message
news:cdm8q0$nfc$1@inn.qnx.com…
Maybe a program is changing it. Run ticksize there and there in the
sysinit, you’ll know at what point the ticksize was change and by who.“Gord Sipko” <> mountkidd@shaw.ca> > wrote in message
news:cdm4fa$k9h$> 1@inn.qnx.com> …
ticksize is being set in sysinit with “ticksize -e 100000”. After
startup
a
check on ticksize shows it as 0.5s. The machine this is running on will
support a ticksize of 0.1s. Why is the sysinit setting being
overridden?
\
Gord Sipko <mountkidd@shaw.ca> wrote:
ticksize is being set in sysinit with “ticksize -e 100000”. After startup a
check on ticksize shows it as 0.5s. The machine this is running on will
support a ticksize of 0.1s. Why is the sysinit setting being overridden?
I assume you mean ms, not seconds.
First, if you do a “ticksize -e 1000000” at the commandline, does it
set it properly to what you want?
Next, comes the question of whether the “right” sysinit file is being
executed.
Go to your sysinit, and insert:
set -v
As the first line, and watch what it does as it boots, to make sure
it is what you expect it to do.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
You are right David, it’s ms not seconds and I do have the right sysinit
file, as ticksize was previously being set to 1ms.
Setting ticksize -e 100000 from the command line does work (ticksize -e
returns the number 99733). It’s the lowest value the OS will accept on the
type of machine I’m working with. If I try ticksize -e and any number <
100000 and > 99733 the OS complains, saying the number is too low.
I’ve tried 110000, 101000, 100100 from the command line and all will set a
value less than that entered. 100100 ends up the same as 100000, ie 99733.
The higher numbers also get rounded down, but to values that are still
higher than 100000.
I’ve tried a variety of numbers via the sysinit file and it always comes
back as 0.5ms (499504 ns).
Gord
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:cdom2n$k81$1@inn.qnx.com…
Gord Sipko <> mountkidd@shaw.ca> > wrote:
ticksize is being set in sysinit with “ticksize -e 100000”. After
startup a
check on ticksize shows it as 0.5s. The machine this is running on will
support a ticksize of 0.1s. Why is the sysinit setting being
overridden?I assume you mean ms, not seconds.
First, if you do a “ticksize -e 1000000” at the commandline, does it
set it properly to what you want?Next, comes the question of whether the “right” sysinit file is being
executed.Go to your sysinit, and insert:
set -v
As the first line, and watch what it does as it boots, to make sure
it is what you expect it to do.-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
“Gord Sipko” <mountkidd@shaw.ca> wrote in message
news:cdphif$atd$1@inn.qnx.com…
You are right David, it’s ms not seconds and I do have the right sysinit
file, as ticksize was previously being set to 1ms.Setting ticksize -e 100000 from the command line does work (ticksize -e
returns the number 99733). It’s the lowest value the OS will accept on
the
type of machine I’m working with. If I try ticksize -e and any number
100000 and > 99733 the OS complains, saying the number is too low.I’ve tried 110000, 101000, 100100 from the command line and all will set a
value less than that entered. 100100 ends up the same as 100000, ie
99733.
The higher numbers also get rounded down, but to values that are still
higher than 100000.I’ve tried a variety of numbers via the sysinit file and it always comes
back as 0.5ms (499504 ns).As I suggest earlier, put the ticksize command a various step in the
sysinit, that should allow you to find
when the ticksize is reseted to .5ms
Gord
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:cdom2n$k81$> 1@inn.qnx.com> …
Gord Sipko <> mountkidd@shaw.ca> > wrote:
ticksize is being set in sysinit with “ticksize -e 100000”. After
startup a
check on ticksize shows it as 0.5s. The machine this is running on
will
support a ticksize of 0.1s. Why is the sysinit setting being
overridden?I assume you mean ms, not seconds.
First, if you do a “ticksize -e 1000000” at the commandline, does it
set it properly to what you want?Next, comes the question of whether the “right” sysinit file is being
executed.Go to your sysinit, and insert:
set -v
As the first line, and watch what it does as it boots, to make sure
it is what you expect it to do.-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Gord Sipko <mountkidd@shaw.ca> wrote:
You are right David, it’s ms not seconds and I do have the right sysinit
file, as ticksize was previously being set to 1ms.Setting ticksize -e 100000 from the command line does work (ticksize -e
returns the number 99733).I’ve tried a variety of numbers via the sysinit file and it always comes
back as 0.5ms (499504 ns).
Ok, so ticksize (from command line) works.
No QNX drivers go out and change the ticksize.
The ticksize program can’t tell if it is being run from the command line,
or if it is being run from within the sysinit script – there is no “special”
sysinit mode or anything. The sysinit is just a shell script, being parsed
and run by the shell.
So, if after boot, you’ve got the wrong value:
- you ran the wrong sysinit script [which is why I said to do the “set -v”]
- you ran something else in the sysinit script that changed the ticksize
after you set it to .1ms - you have more than one program called ticksize on the system, and the
sysinit has a different path from your shell, and so runs a different
ticksize utility.
So, in your sysinit, right after you try to set your .1ms ticksize, do a
ticksize -e to check what you got. Is it what you expected?
Try a “which -laf ticksize” in your sysinit, and at the shell prompt to make
sure it is the same ticksize utility.
Run your sysinit with the first line as “set -v”.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
I added the set -v as well as a check on the return code from the ticksize
call - no real useful information from either as everything returned OK!
I then moved the set ticksize to the end of the sysinit file, immediately
before the tinit call and it worked. Backtracking, there was a call to
mousetrap, Dosfsys and nameloc. I commented out each in turn and the
problem is mousetrap - there is some side effect from this call. Don’t know
why this should be, but who cares - there is a workaround.
The workaround is to do the set ticksize after the call to mousetrap!
Thanks for all your suggestions.
Gord
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:ce3jmm$s46$1@inn.qnx.com…
Gord Sipko <> mountkidd@shaw.ca> > wrote:
You are right David, it’s ms not seconds and I do have the right sysinit
file, as ticksize was previously being set to 1ms.Setting ticksize -e 100000 from the command line does work (ticksize -e
returns the number 99733).I’ve tried a variety of numbers via the sysinit file and it always comes
back as 0.5ms (499504 ns).Ok, so ticksize (from command line) works.
No QNX drivers go out and change the ticksize.
The ticksize program can’t tell if it is being run from the command line,
or if it is being run from within the sysinit script – there is no
“special”
sysinit mode or anything. The sysinit is just a shell script, being
parsed
and run by the shell.So, if after boot, you’ve got the wrong value:
- you ran the wrong sysinit script [which is why I said to do the
“set -v”]- you ran something else in the sysinit script that changed the ticksize
after you set it to .1ms- you have more than one program called ticksize on the system, and the
sysinit has a different path from your shell, and so runs a different
ticksize utility.So, in your sysinit, right after you try to set your .1ms ticksize, do a
ticksize -e to check what you got. Is it what you expected?Try a “which -laf ticksize” in your sysinit, and at the shell prompt to
make
sure it is the same ticksize utility.Run your sysinit with the first line as “set -v”.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
Gord Sipko <mountkidd@shaw.ca> wrote:
I added the set -v as well as a check on the return code from the ticksize
call - no real useful information from either as everything returned OK!I then moved the set ticksize to the end of the sysinit file, immediately
before the tinit call and it worked. Backtracking, there was a call to
mousetrap, Dosfsys and nameloc. I commented out each in turn and the
problem is mousetrap - there is some side effect from this call. Don’t know
why this should be, but who cares - there is a workaround.The workaround is to do the set ticksize after the call to mousetrap!
Ah, I bet I know what is happening. I think mousetrap needs a
smaller ticksize than 10ms (the default), so it (quite properly)
queries the ticksize, saves that away, sets the ticksize to what
it needs, then tries to restore the ticksize…and fails.
Basically the sequence ends up being:
ticksize -e 100000 /* you /
ticksize -e / mousetrap queries & stores /
reports: 99733
ticksize -e 500000 / for trapping mice /
ticksize -e 99733 / and fails on the restore */
error: nanosecond value too small
It is a bug in mousetrap – but with a simple work-around (as you
found), so I don’t expect it will get fixed.
-David
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com