Ton_Kostelijk

Ton Kostelijk 

2 June 2010

Ik werk aan zeer ingewikkelde systemen die vooral bestaan uit elektronica en software. Als echte systeemarchitect heb ik over alle aspecten van deze systemen, en de organisatie daaromheen, meningen die kloppen. Dit komt door mijn inzichten en ervaring. Mijn omgeving vaart daar blind op. Ja, als figuurlijke broer van Arie Ribbens is het moeilijk bescheiden te blijven.

Maar niet heus. De grootste eureka-ervaringen heb ik gekregen toen ik overtuigd van mijzelf aan het blunderen was en vervolgens langzaam en pijnlijk het inzicht kreeg dat er iets niet klopte. Dit kwam meestal doordat anderen terecht mijn mening niet voor zoete koek slikten.

Een voorbeeld? Bij software is task-switchingoverhead iets om je druk over te maken. Die overhead is typisch tussen de vijf en twintig procent van de processortijd. Een tijdje geleden werkte ik aan een combi-product: twee softwarestacks moesten tegelijkertijd op één processor draaien en toch blijven voldoen aan realtime-eisen. Hierbij is het aantal task-switches dus belangrijk. Intuïtief was het helder: die stacks gaan elkaar in de weg zitten. Dat geeft dus in totaal meer task-switches dan de som van beide stacks afzonderlijk natuurlijk.

In een onbewaakt maar ijverig moment heb ik task-switchmetingen met elkaar vergeleken. Wat bleek: voor de combi is het totaal aan task-switches lager. Mijn reacties waren: 1. de metingen kloppen niet, 2. dit is een toevallige uitzondering, laten we meer situaties meten, 3. er is iets speciaals aan de hand, en nog een paar meer. Ja, een overtuiging doet er alles aan om stand te houden.

Techwatch Books: ASML Architects

Toen ben ik eens dieper gaan brainstormen met mijzelf en anderen. Wat blijkt? Die intuïtie, daar klopt in dit geval niets van. Het complete bewijs vergt twaalf kantjes. Belangrijk is het besef dat één stack ook al de processortijd deelt met iets anders: de idle task. Al draaiend schakelt de processor heen en weer tussen deze taak en die van de stack. Of hij nu naar de idle task gaat of naar een taak van een andere softwarestack, voor het aantal task-switches maakt dat niet uit. Dat aantal in een combi zou dus gelijk moeten zijn aan de som van de beide stacks, geïsoleerd draaiend. Hoe het totaal dan toch lager kan zijn? Omdat elke switch die voor een geïsoleerde stack naar idle zou gaan bij de combi een kans heeft om direct naar de andere stack te gaan, wat één switch vanaf idle bespaart. Ja, gelukkig is het ingewikkeld. Zo heb ik tenminste een excuus voor mijn fout.

Meestal wisselen we kennis uit door onze successen te vertellen. Zou het niet veel beter zijn als we elkaar onze blunders vertellen, en hoe die ons werkelijk de grootste aha‘s opleverden? Bij informele contacten bij de koffie lukt dit wel. Maar denk ook aan conferenties en workshops, die kunnen zo toch veel boeiender worden. Ik heb er al een mooie titel voor: het Foutenfestival.