Which raises another question: are 9atom and 9front in synch with the
BL distribution (itself in question) regarding syscall 53?
9atom is not. i didn't know that it was added, nor do i
know why nsec was added as a syscall.
i indirectly heard go needs it, but that is not really a reason
i can
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important alert, quite indirectly: when using
high resolution timers, the issue of opening a device, reading it and
converting the input value to a
On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote:
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important alert, quite indirectly: when using
high resolution timers, the issue
On Mon May 19 12:26:00 EDT 2014, quans...@quanstro.net wrote:
On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote:
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important
i took a quick look at the runtime·nanotime, and it looks like it's being
used for gettimeofday, which shouldn't be super performance sensitive.
I'm on thin ice here, but I seem to remember that the crucial issue
was the resolution (nanosecond) and the expectation that Plan 9 would
have to
also, one cannot get close to 1ns precision with a system call. a system call
takes a bare minimum of 400-500ns on 386/amd64.
Sure, but accessing /dev/time is, if I guess right, orders of
magnitude slower, specially if you have to open the device first.
As far as I know, that was the only
On Mon May 19 13:17:59 EDT 2014, lu...@proxima.alt.za wrote:
also, one cannot get close to 1ns precision with a system call. a system
call
takes a bare minimum of 400-500ns on 386/amd64.
Sure, but accessing /dev/time is, if I guess right, orders of
magnitude slower, specially if you
On 19 May 2014 18:13, lu...@proxima.alt.za wrote:
Curiously, I'm pretty certain that it was the issue of an fd that
remained open (something to do with caching the /dev/time fd, if I
remember right) that caused some tests to fall apart, probably because
a test for leaking fds actually needed
On 19 May 2014 18:13, lu...@proxima.alt.za wrote:
Curiously, I'm pretty certain that it was the issue of an fd that
remained open (something to do with caching the /dev/time fd, if I
remember right) that caused some tests to fall apart, probably because
a test for leaking fds actually
i've been thinking about ainc() and for the amd64 implementation,
TEXT ainc(SB), 1, $-4 /* int ainc(int*) */
MOVL$1, AX
LOCK; XADDL AX, (RARG)
ADDL$1, AX
RET
does anyone know if the architecture
There are two separate issues here. First, there's the issue of
whether 9front and 9atom should incorporate the change.
For purely egoistic reasons, I'd like that, regardless of the
technical merits of the change. I regulary test labs software on
9front. It would be a pity if I couldn't do that
On 19 May 2014 20:15, Aram Hăvărneanu ara...@mgk.ro wrote:
Some people claimed
that using it leaked file descriptors in multithreaded programs. I
don't understand why this problem can't be solved by opening it
close-on-exec.
The optimisation was a static int file descriptor.
That was
The LOCK prefix is effectively a tiny, tiny mutex, but for all intents
and purposes, this is wait-free. The LOCK prefix forces N processors
to synchronize on bus and cache operations and this is how there is a
guarantee of an atomic read or an atomic write. For instructions like
cmpxchg and xadd
On Mon, 19 May 2014 13:25:42 EDT erik quanstrom quans...@quanstro.net wrote:
i would be very surprised if there were any gain in accuracy. the
accuracy is going to be dominated by the most inaccurate term, and
that's likely going to be timesync, and on the order of milliseconds.
Speaking of
I am adding some logic to synchronize with the PPS signal from
the GPS device that I hooked up to a RaspberryPi. With this
change the TOD clock should be accurate to within 10 to 20 µs.
So I for one welcome the new syscall! [Though its introduction
could've been better managed]
even a
On Mon May 19 15:51:27 EDT 2014, devon.od...@gmail.com wrote:
The LOCK prefix is effectively a tiny, tiny mutex, but for all intents
and purposes, this is wait-free. The LOCK prefix forces N processors
to synchronize on bus and cache operations and this is how there is a
guarantee of an atomic
There was another complaint about /dev/bintime. Some people claimed
that using it leaked file descriptors in multithreaded programs. I
don't understand why this problem can't be solved by opening it
close-on-exec. In fact, this problem doesn't exist in the port of
Go to Plan 9 anymore
I've been watching the discussion but was hesitant to jump in. But
somebody asked me to say a thing or two.
We put the nsec() system call into NxM because, any way you cut it, it
provides better accuracy than the open/read/close path, particularly
when there's lots of stuff running, and the apps
So you seem to be worried that N processors in a tight loop of LOCK
XADD could have a single processor. This isn't a problem because
locked instructions have total order. Section 8.2.3.8:
The memory-ordering model ensures that all processors agree on a
single execution order of all locked
On 19 May 2014 21:54, ron minnich rminn...@gmail.com wrote:
jitter-free time
Jitter says something about (in)consistency of time periods or intervals.
It will be a function of scheduling decisions, not the overhead of a single
call.
In Nix, on an AP core, sure, because there isn't any
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
Jitter says something about (in)consistency of time periods or intervals. It
will be a function of scheduling decisions, not the overhead of a single
call.
In Nix, on an AP core, sure, because there isn't any
On Mon May 19 17:02:57 EDT 2014, devon.od...@gmail.com wrote:
So you seem to be worried that N processors in a tight loop of LOCK
XADD could have a single processor. This isn't a problem because
locked instructions have total order. Section 8.2.3.8:
The memory-ordering model ensures that all
On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote:
the documentation appears not to cover this completely.
Hmm. You put documentation and completely in the same sentence. Agents
are converging on your house. Run!
There's always an undocumented progress engine
On Mon May 19 18:15:21 EDT 2014, rminn...@gmail.com wrote:
On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote:
the documentation appears not to cover this completely.
Hmm. You put documentation and completely in the same sentence. Agents
are converging on your
Quoting ron minnich rminn...@gmail.com:
And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which boiled down to:
if you can do it with a single system call, you should with a
response of we put in a patch, was not accepted yet.. I just renewed
the
golang-dev has more clout than 9fans nowadays, at least as it pertains to plan9.
On Mon, May 19, 2014 at 5:02 PM, Kurt H Maier k...@sciops.net wrote:
Quoting ron minnich rminn...@gmail.com:
And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which
Quoting andrey mirtchovski mirtchov...@gmail.com:
golang-dev has more clout than 9fans nowadays, at least as it
pertains to plan9.
That's why I'm asking. We now have three go-related new syscalls, while
lots of actual hardware support gets flushed down the toilet for
unspecified reasons.
I suggest personal notes, flowers, and some hard liquor.
On Mon, May 19, 2014 at 5:12 PM, Kurt H Maier k...@sciops.net wrote:
Quoting andrey mirtchovski mirtchov...@gmail.com:
golang-dev has more clout than 9fans nowadays, at least as it pertains to
plan9.
That's why I'm asking. We now
On May 19, 2014, at 6:17 PM, andrey mirtchovski mirtchov...@gmail.com wrote:
I suggest personal notes, flowers, and some hard liquor.
/me could use all three after a weekend of sysadmin frustration.
All hope is not lost… this exercise, by not being able to use
my usual cpu servers, gave me
2014-05-19 18:05 GMT-04:00 erik quanstrom quans...@quanstro.net:
On Mon May 19 17:02:57 EDT 2014, devon.od...@gmail.com wrote:
So you seem to be worried that N processors in a tight loop of LOCK
XADD could have a single processor. This isn't a problem because
locked instructions have total
It is an ordering, but I don't think it's a valid one: your ellipses
suggest an unbounded execution time (given the context of the
discussion). I don't think that's valid because the protocol can't
possibly negotiate execution for more instructions than it has space
for in its pipeline.
added the syscall for binary compatibility with sources to 9front kernel.
nsec() remains a library function that reads /dev/bintime. removed the
filedescriptor caching from nsec() like in the 9atom version.
--
cianp
32 matches
Mail list logo
