Your face almost impossibly similar to Rando Tomson from city with name Viljandi.

On Monday, July 3, 2023 at 4:09:48 PM UTC+3, David Brown wrote:
> On 03/07/2023 12:42, Frederick Virchanza Gotham wrote:
> >
> > I'm writing a network analysis program, and just today I've found out that it's too slow and missing packets.
> >
> > Ideally, I want the thread that reads from the network card to have exclusive use of one of the CPU cores.
> >
> > I'm looking at the following two functions:
> > sched_setaffinity
> > pthread_setaffinity_np
> >
> > And I note the following in the Linux manual:
> > "For example, by dedicating one CPU to a particular process (i.e., setting the affinity mask of that process to specify a single CPU, and setting the affinity mask of all other processes to exclude that CPU), it is possible to ensure maximum execution speed for that process"
> >
> > I can find lots and lots of code examples to set the affinity for one thread or for one process -- however I cannot find one code example showing me how to exclude all other threads.
> >
> > There's absolutely no point in me restricting my thread to the 1st CPU core if other threads can run on that core too -- in fact that will make my program _slower_ because my thread can't be scheduled on the other cores. Every code sample I can find online seems to just restrict the thread in question without placing any restriction on other threads.
> >
> > Anyone know how this is supposed to work?
> "cpu isolation" is, I believe, the term you want to look for on Google.
> I don't know if this can only be set from boot parameters or configured
> at run-time. You could also search for real-time linux, as that is
> where these features are often used.
>
> You will probably also want to disable some or all power-down modes and
> clock speed switching, as these can give significant variations in
> latencies. And you may need to pin the network card interrupts to a
> processor core too.

Am 08.07.2023 um 21:08 schrieb Chris M. Thomasson:
> On 7/8/2023 7:19 AM, Bonita Montero wrote:
>> Am 08.07.2023 um 14:51 schrieb David Brown:
>>
>>> I've tried to explain things to you, as has Scott.  Clearly, it is
>>> all  so far beyond you that the Dunning Kruger effect has taken over.
>>
>> His reasoning is really 180 degrees opposite of mine,
>> to an extent that is easily recognizable as fantasy.
>>
>>
>
> Is this a projection?

No, a very good knowledge of human nature.

Am 08.07.2023 um 20:28 schrieb Muttley@dastardlyhq.com:
> On Sat, 8 Jul 2023 18:01:12 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>> How do you think online multiplayer RPGs work?
>>
>> The only transfer a small amout of state about the player over the
>
> There's also a large amount of state about everything else going on
> in the simulated world that has to be uploaded to each player which
> has to be kept in sync.

I'm pretty sure you've never worked on things like that.

Am 08.07.2023 um 20:45 schrieb Chris M. Thomasson:

> I think a lot of them (games) use UDP instead of TCP.

Of course. That's while you don't need re-transmits because
they would reach the other parties too late anyway.

On 7/8/2023 12:24 PM, Bonita Montero wrote:
> Am 08.07.2023 um 21:08 schrieb Chris M. Thomasson:
>> On 7/8/2023 7:19 AM, Bonita Montero wrote:
>>> Am 08.07.2023 um 14:51 schrieb David Brown:
>>>
>>>> I've tried to explain things to you, as has Scott.  Clearly, it is
>>>> all  so far beyond you that the Dunning Kruger effect has taken over.
>>>
>>> His reasoning is really 180 degrees opposite of mine,
>>> to an extent that is easily recognizable as fantasy.
>>>
>>>
>>
>> Is this a projection?
>
> No, a very good knowledge of human nature.
>

Are you some sort of oracle? ;^)

V <vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvva@hotmail.com>
writes:
> Your face almost impossibly similar to Rando Tomson from city with name Viljandi.
[...]

"V", I've seen several posts from you here in comp.lang.c++ lately.
None of them have anything to do with C++.

Are you planning to participate in any meaningful way?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 08/07/2023 22:57, Keith Thompson wrote:
> V <vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvva@hotmail.com>
> writes:
>> Your face almost impossibly similar to Rando Tomson from city with name Viljandi.
> [...]
>
> "V", I've seen several posts from you here in comp.lang.c++ lately.
> None of them have anything to do with C++.
>
> Are you planning to participate in any meaningful way?
>

'V' is Kristjan Robam - and no he isn't. Time to update your killfile.

On 7/8/2023 12:26 PM, Bonita Montero wrote:
> Am 08.07.2023 um 20:45 schrieb Chris M. Thomasson:
>
>> I think a lot of them (games) use UDP instead of TCP.
>
> Of course. That's while you don't need re-transmits because
> they would reach the other parties too late anyway.
>

Actually, I remember way back on my nt 4.0 days, this might of been
around 2001-2002 ish... I would have a single TCP connection for control
then a bunch on UDP connections to send datagrams.

Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson:

> Actually, I remember way back on my nt 4.0 days, this might of
> been around 2001-2002 ish... I would have a single TCP connection
> for control then a bunch on UDP connections to send datagrams.

I'm pettifogging: you never had UDP-_connections_.

On 7/9/2023 1:44 AM, Bonita Montero wrote:
> Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson:
>
>> Actually, I remember way back on my nt 4.0 days, this might of
>> been  around 2001-2002 ish... I would have a single TCP connection
>> for control then a bunch on UDP connections to send datagrams.
>
> I'm pettifogging: you never had UDP-_connections_.
>
>

It was many years ago. Iirc, I would have a single TCP connection for
status and send out datagrams via UDP. It was kind of like the zmodem
protocol. I remember using a multiplex in the TCP connection to embedded
multiple status messages for different sockets. UDP was the main usage.
TCP was there to maintain a lossless comm. UDP datagrams can get lost
and/or duplicated, iirc.

On 7/9/2023 2:41 AM, Chris M. Thomasson wrote:
> On 7/9/2023 1:44 AM, Bonita Montero wrote:
>> Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson:
>>
>>> Actually, I remember way back on my nt 4.0 days, this might of
>>> been  around 2001-2002 ish... I would have a single TCP connection
>>> for control then a bunch on UDP connections to send datagrams.
>>
>> I'm pettifogging: you never had UDP-_connections_.
>>
>>
>
> It was many years ago. Iirc, I would have a single TCP connection for
> status and send out datagrams via UDP. It was kind of like the zmodem
> protocol. I remember using a multiplex in the TCP connection to embedded
> multiple status messages for different sockets. UDP was the main usage.
> TCP was there to maintain a lossless comm. UDP datagrams can get lost
> and/or duplicated, iirc.

I remember putting in some state in the datagrams. So, if they arrived
out of order, I could put them back together. Or, they just knew where
to be written to a memory mapped file.

On 7/9/2023 1:44 AM, Bonita Montero wrote:
> Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson:
>
>> Actually, I remember way back on my nt 4.0 days, this might of
>> been  around 2001-2002 ish... I would have a single TCP connection
>> for control then a bunch on UDP connections to send datagrams.
>
> I'm pettifogging: you never had UDP-_connections_.

Basically, I would try to send a file offset in the datagrams. The
receiver of a single datagram knew where to write it in a memory mapped
file.

On 7/9/2023 2:55 AM, Chris M. Thomasson wrote:
> On 7/9/2023 1:44 AM, Bonita Montero wrote:
>> Am 09.07.2023 um 07:47 schrieb Chris M. Thomasson:
>>
>>> Actually, I remember way back on my nt 4.0 days, this might of
>>> been  around 2001-2002 ish... I would have a single TCP connection
>>> for control then a bunch on UDP connections to send datagrams.
>>
>> I'm pettifogging: you never had UDP-_connections_.
>
>
> Basically, I would try to send a file offset in the datagrams. The
> receiver of a single datagram knew where to write it in a memory mapped
> file.

Damn Bonita! You are making my brain think of things I did long ago...

This is why I had a TCP connection to be able to reliably request more
data until the memory mapped file was full via UDP datagrams filling it
up, so to speak...

:^D

On 08/07/2023 16:19, Bonita Montero wrote:
> Am 08.07.2023 um 14:51 schrieb David Brown:
>
>> I've tried to explain things to you, as has Scott.  Clearly, it is
>> all  so far beyond you that the Dunning Kruger effect has taken over.
>
> His reasoning is really 180 degrees opposite of mine,

Yes - because he knows what he is talking about - he has the computers
there, in his lab - and you haven't a clue. Can you really not see that?

On 7/9/2023 3:38 AM, David Brown wrote:
> On 08/07/2023 16:19, Bonita Montero wrote:
>> Am 08.07.2023 um 14:51 schrieb David Brown:
>>
>>> I've tried to explain things to you, as has Scott.  Clearly, it is
>>> all  so far beyond you that the Dunning Kruger effect has taken over.
>>
>> His reasoning is really 180 degrees opposite of mine,
>
> Yes - because he knows what he is talking about - he has the computers
> there, in his lab - and you haven't a clue.  Can you really not see that?
>
>

YIKES! ;^/

On 08/07/2023 20:28, Muttley@dastardlyhq.com wrote:
> On Sat, 8 Jul 2023 18:01:12 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>> How do you think online multiplayer RPGs work?
>>
>> The only transfer a small amout of state about the player over the
>
> There's also a large amount of state about everything else going on
> in the simulated world that has to be uploaded to each player which has to be
> kept in sync.
>

Yes, that would be another type of application where the server would
need very fast network card(s). It's a different case from Scott's,
since online games generally aim for smaller amounts of data at a time
but handle vast numbers of connections (hundreds of thousands, or more)
and also want lower latencies. For Scott's file servers, there are only
hundreds of client machines, but the data files are very large and the
simulations generate massive quantities of data as they go along. But
it is certainly an application for which you want as fast networking as
you can afford on the server.

On 7/9/2023 3:43 AM, David Brown wrote:
> On 08/07/2023 20:28, Muttley@dastardlyhq.com wrote:
>> On Sat, 8 Jul 2023 18:01:12 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>>> How do you think online multiplayer RPGs work?
>>>
>>> The only transfer a small amout of state about the player over the
>>
>> There's also a large amount of state about everything else going on
>> in the simulated world that has to be uploaded to each player which
>> has to be
>> kept in sync.
>>
>
> Yes, that would be another type of application where the server would
> need very fast network card(s).  It's a different case from Scott's,
> since online games generally aim for smaller amounts of data at a time
> but handle vast numbers of connections (hundreds of thousands, or more)
> and also want lower latencies.  For Scott's file servers, there are only
> hundreds of client machines, but the data files are very large and the
> simulations generate massive quantities of data as they go along.  But
> it is certainly an application for which you want as fast networking as
> you can afford on the server.
>

Fwiw, I am wondering of anybody else got pissed off at the nt 4.0 client
version only allowing for two concurrent TransmitFile IOCP functions to
be allowed at any one time? The nt 4 server allowed for enough
concurrent TransmitFile's to blow the non-paged memory. Grrr!

Am 09.07.2023 um 11:41 schrieb Chris M. Thomasson:

> On 7/9/2023 1:44 AM, Bonita Montero wrote:

>> I'm pettifogging: you never had UDP-_connections_.

> It was many years ago. Iirc, ...

UDP is connectionless and stateless.

On Sat, 8 Jul 2023 21:25:16 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 08.07.2023 um 20:28 schrieb Muttley@dastardlyhq.com:
>> On Sat, 8 Jul 2023 18:01:12 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>>> How do you think online multiplayer RPGs work?
>>>
>>> The only transfer a small amout of state about the player over the
>>
>> There's also a large amount of state about everything else going on
>> in the simulated world that has to be uploaded to each player which
>> has to be kept in sync.
>
>I'm pretty sure you've never worked on things like that.
>

Bonita playbook rule #1: If proven wrong accuse other person of knowing
nothing/being an idiot/lying etc.

Perhaps look in the mirror occasionally.

Am 09.07.2023 um 14:18 schrieb Muttley@dastardlyhq.com:
> On Sat, 8 Jul 2023 21:25:16 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 08.07.2023 um 20:28 schrieb Muttley@dastardlyhq.com:
>>> On Sat, 8 Jul 2023 18:01:12 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>>>> How do you think online multiplayer RPGs work?
>>>>
>>>> The only transfer a small amout of state about the player over the
>>>
>>> There's also a large amount of state about everything else going on
>>> in the simulated world that has to be uploaded to each player which
>>> has to be kept in sync.
>>
>> I'm pretty sure you've never worked on things like that.
>>
>
> Bonita playbook rule #1: If proven wrong accuse other person of knowing
> nothing/being an idiot/lying etc.
> Perhaps look in the mirror occasionally.

If you make realtime transfers you can't afford to make
large transfers because they'd have a large latency until
being received by other parties.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 7/9/2023 3:43 AM, David Brown wrote:
>> On 08/07/2023 20:28, Muttley@dastardlyhq.com wrote:
>>> On Sat, 8 Jul 2023 18:01:12 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>>>> How do you think online multiplayer RPGs work?
>>>>
>>>> The only transfer a small amout of state about the player over the
>>>
>>> There's also a large amount of state about everything else going on
>>> in the simulated world that has to be uploaded to each player which
>>> has to be
>>> kept in sync.
>>>
>>
>> Yes, that would be another type of application where the server would
>> need very fast network card(s).  It's a different case from Scott's,
>> since online games generally aim for smaller amounts of data at a time
>> but handle vast numbers of connections (hundreds of thousands, or more)
>> and also want lower latencies.  For Scott's file servers, there are only
>> hundreds of client machines, but the data files are very large and the
>> simulations generate massive quantities of data as they go along.  But
>> it is certainly an application for which you want as fast networking as
>> you can afford on the server.
>>
>
>Fwiw, I am wondering of anybody else got pissed off at the nt 4.0 client
>version only allowing for two concurrent TransmitFile IOCP functions to
>be allowed at any one time? The nt 4 server allowed for enough
>concurrent TransmitFile's to blow the non-paged memory. Grrr!

Can't say I've ever actually used NT4 for anything. Or any windows
release for that matter. In the NT4 timeframe, I was still using large
IRIX machines and NT was considered a toy. We did have a source license
for NT4 and modified it to use as one of our supported guest OS' in early
hypervisor skunkwork (1998/1999) at SGI, so I was, at the time, quite familiar
with the NTOS portions of windows (which were strikingly similar to the
VAX VMS internals that I worked with in the early 80's).

On 07/07/2023 19:31, Kalevi Kolttonen wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> RTL (Register Transfer Language)
>
> When reading GCC documentation many years ago, I came
> across this RTL:
>
> https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gccint/RTL.html
>
> Does it have anything to do with the RTL you guys use?
>

In both cases, the abbreviation means "Register transfer level". But
they are different kinds of register.

For the compiler, you are talking about processor registers (typically
matching a 32-bit or 64-bit integer, double precision floating point, or
possibly SIMD vector). RTL is then about transforming the program into
virtual operations that are register to register, or register op
register to register.

In logic design, whether it be programmable logic (FPGA's), ASICs, or
full-blown digital logic chips, a "register" is a single storage bit,
and RTL covers input to the register as combinational logic of signals,
clocking, enables, reset lines, and possible asynchronous overrides.
There's a lot that goes on for each single bit here, to describe it and
how it works, to simulate it, and to record its state and output. It's
not just the logical states - timing has to be taken into account too.
And while you can do bulk simulation for things like caches and static
rams, there are still hundreds of millions of gates to simulate in these
big chips.

(There are also other kinds of simulations needed for power usage,
timing closure, fanouts, etc.)

On 7/9/2023 4:46 AM, Bonita Montero wrote:
> Am 09.07.2023 um 11:41 schrieb Chris M. Thomasson:
>
>> On 7/9/2023 1:44 AM, Bonita Montero wrote:
>
>>> I'm pettifogging: you never had UDP-_connections_.
>
>> It was many years ago. Iirc, ...
>
> UDP is connectionless and stateless.
>

Just read datagrams from a bound socket.

David Brown <david.brown@hesbynett.no> writes:
> On 07/07/2023 19:31, Kalevi Kolttonen wrote:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> RTL (Register Transfer Language)
>> When reading GCC documentation many years ago, I came
>> across this RTL:
>> https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gccint/RTL.html
>> Does it have anything to do with the RTL you guys use?
>>
>
> In both cases, the abbreviation means "Register transfer level". But
> they are different kinds of register.
[...]

In the gcc documentation, RTL means "Register Transfer Language".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 10/07/2023 01:09, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/07/2023 19:31, Kalevi Kolttonen wrote:
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> RTL (Register Transfer Language)
>>> When reading GCC documentation many years ago, I came
>>> across this RTL:
>>> https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gccint/RTL.html
>>> Does it have anything to do with the RTL you guys use?
>>>
>>
>> In both cases, the abbreviation means "Register transfer level". But
>> they are different kinds of register.
> [...]
>
> In the gcc documentation, RTL means "Register Transfer Language".
>

Thanks for the correction.

GCC's RTL is the internal language / notation / data structure at the
register transfer level. In either case, we are talking about
registers, and transfer of data into and out of them - the same name,
and related concepts, but major differences nonetheless when talking
about the inner workings of compilers, and digital hardware designs.
They are close enough for potential confusion, and I hope I've made
things a little clearer for folks here unfamiliar with hardware design
languages.