My OS is QNX V6.3 + multi-core TDK!
I want to set this cpu0 and cpu1.
There is two processes → “greedy1” and “greedy2”
I use this command “on” .
#on -C0 ./greedy1
#on -C1 ./greedy2
This case is normal. The greedy1 run on the cpu0.
The greedy2 run on the cpu1.
There are two network cards. (i82544 and rtl)
I want the “i82544” to run on the cpu0 and the “rtl” to run on the cpu1.
How do I use the command “on” to set the cpu?
not so easy, since the network drivers run as DLLs that plug in to io-net. Bound multiprocessing applies to processes as a whole, not to individual DLLs that they load. One possibility would certainly be to run two completely independent instances of io-net:
#on -C0 io-net -drtl -ptcpip
#on -C1 io-net -di82544 -ptcpip
but that implies that you also have two independent TCP/IP stacks running that more or less transparently overlay each other, and I’m not sure what side-effects this may have in your system.
It’s also probably worth thinking about what this segregation would mean. io-net (take a good look at the name) is not a very cpu bound process. The possibility that one io-net thread is stealing too many cycles from the other, well it doesn’t make sense to me.
Usually bounding process to a fix cpu is not a good, why do you want to do that?
If binding a program to a fixed CPU is not a good, why did QSSL invent this feature? Because it allows you to safely run a program on a SMP machine that was not originally written to be SMP-aware and hence would maybe fail in an SMP environment although it ran stable on a single-processor machine. Bound multiprocessing is just a tool to ease migration of your software to SMP environments.
In case of io-net (including the drivers mentioned above), which was written by or on behalf of QSSL itself, I hope it was written with SMP in mind and hence it should not be necessary to bind it to a fixed CPU.
It also serves a purpose that may now be no longer necessary. By segregating processes on processors, you can guarentee that a particular process won’t get starved by a runaway process. A new scheduler option in 6.3 allows for virtual processors that can do the same thing with more flexibility.
What kind of new scheduler do you mean? Virtual processors? Are you referring to Adaptive Partitioning?
Adaptive Partitioning is not the same as binding, plus Adaptive Partitioning is very expensive.
To Thunderblade, yes I’m talking about Adaptive Partitioning. The term virtual processor is something I heard from a QSSL employee and I think it is appropriate. You can create a partition which is guarenteed some percentage of the cycles. This is better than cpu binding in that the extra cycles are never wasted. I don’t know anything about the cost.
Thanks maschoen. To mario - in my experience price is a matter of negotiation. Anyway - I like AP, but I don’ think it’s really necessary when you have a clean system design. OTOH, who has that?
Well the one place I see it being real useful is on the road to clean system design. One of the standard problems that used to come up when testing under QNX 4 was the cpu lock out. Something went wrong, and a shell at the standard priority would not respond. It would have been nice under those circumstances to reserve a partition for a shell that would always work. I use a multi-processor system now, so I haven’t run into this problem on QNX 6.
A 90% reduction in price still made it too expensive for us
Not really, there are designs that cannot be implemented without AP. How can you for example run a program that checks HD integrity (chkfsys) that uses no more then 5% of CPU.
This code can set the multi io-net to run the multi cpu
on -C 0 /sbin/io-net -i1 -dvia-rhine pci=0 -ptcpip
on -C 1 /sbin/io-net -i2 -dvia-rhine pci=0 -ptcpip
thansks! all friends supply me !
You didn’t answer why you would want to do that, what is the purpose. What advantage do you get? This could actually degrade performance.
This function is for my project! I know that could actually degrade performance!
But the designer is my boss.
If the network card1 would bad. the card2 could work normal!
I don’t see how this is relevant to a card going bad. If he things this is going to protect the system in case a network card goes bad, he is wrong. For example f this is an X86 typically all interrupts are routed to processor #0…
Yes and no. If network card1 is bad, it could 1) affect nothing else, 2) stop the other card from working, or 3) stop everything from working. Segregating the cpu resource does nothing to help any of these situations. For that to be, the cpu’s would have to each have their own separate I/O channels, and in that case, you would not have SMP.