> The server’s apparent WCET is only 2W if the client fails to ensure that it’s 
> got enough budget left. That’s a client bug, the client can ensure that it 
> invokes the server with a fresh budget. It’s not the kernel’s job to ensure 
> that buggy clients get optimal service.

I see. Though wouldn't it make more sense for the server to check, instead of 
the client? Because the server needs to check anyway, so that a misbehaving 
client can't DoS other clients by repeatedly calling the server with 
insufficient budget and forcing the server to repeatedly time out and recover. 
And because the server is in a better position to handle its data-dependent 
execution times (i.e. as you said, not just pessimistically bail if remaining 
budget < WCET). So, the client can call unconditionally, the server can return 
an error code whenever it discovers it won't be able to finish in time, and the 
client's error checking doesn't depend on timing info about the server.

Anyway, that made me think of where else limited server time is a problem. At 
19:13 in your presentation “Mixed-criticality support in seL4” at you gave the example of network 
drivers needing timely response to avoid packet loss. The solution at 30:47 was 
a scheduling context with high priority, short period, and budget<period to 
limit utilization, which allowed a deadline guarantee for a higher-criticality 
thread, and allowed a low-criticality thread to use the slack.

But network traffic might be mixed criticality. For example, real-time sensor 
data mixed with bulk file transfers. Suppose the most critical thread must be 
allocated 90% to cover its worst case utilization, but its average is 20%. The 
network driver then can be allocated only 10%, but it's plenty to transceive 
the critical traffic. Suppose also that to saturate the network link, the bulk 
transfer thread (which runs as slack) would need 50% and the network driver 
would need 20% (twice its allocation) to transceive fast enough. In this case, 
total utilization will average less than 80%, and the bulk transfer will be 
unnecessarily throttled.

One solution would be to assign two contexts to the network driver: the 
standard 10% high priority context and a 100% low-priority context, and run the 
driver whenever either context allows. Then average total utilization could 
rise to 90% (with 20% for the network driver) to avoid throttling the bulk 

But at 23:04 in your presentation, you explained that with traditional time 
slicing, one client can DoS another if it doesn't have to pay the time cost of 
running a high-priority server, and the solution at 32:03 is running the server 
using the client's budget, which gives me another idea: why give the network 
driver an independent budget at all? Even if the driver needs a short period, 
it still makes sense to run using the client's budget. It's pointless to avoid 
dropping packets if the client is too slow to consume them anyway, which means 
the client must be guaranteed suitable utilization; therefore, simply guarantee 
enough additional utilization to cover the cost of the network driver's 
service, and when the driver transceives data on the client's behalf, charge 
the client for the time.

That way, there's no need for a second driver context to fully serve the slack 
thread, nor even a need for one complete context (with budget) to serve the 
most critical thread.

BTW, at 40:42, you described a UAV system with an A15-based mission board and 
an M3-based flight control board, which you said you would have designed to be 
more simple if not representing a legacy system. In particular, would you 
eliminate the separate flight control MCU, and run everything on one CPU?

Devel mailing list

Reply via email to