Please note that this is a secondary copy of a file in the gryphon/sched directory on Dearborn Group CVS, so you may want to check there in case a later version exists. Differences between critical and normal schedules. -------------------------------------------------- Both critical and normal scheduler jobs are started with the same command, CMD_SCHED_TX, with just a single bit in the global flags field to distinguish between the two. To the user they may seem very similar but the two types of jobs are actually implemented _very_ differently. Each non critical job runs in its own space as a normal process on Gryphon under the control of the Gryphon's operating system, which allocates machine resources to the job as it sees fit. Typically there will be plenty of resources available and the job will run as intended. However, in certain situations the demands for machine resources (e.g. processing power, network bandwidth, memory availability, etc) can exceed the amount available and non- critical scheduler jobs will run slower than intended. In contrast, critical jobs are implemented by code embedded into the operating system. Resources to run them are permanently reserved for them and can't be used for anything else, even during periods when they are not used at all. This means certain limitations have to be imposed on critical jobs, but the resources are instantly available whenever the jobs need them. Gryphon will try its hardest to transmit messages at the times specified at nearly all costs (not dropping vehicle/controller network messages has equal importance as transmitting critical messages). It is possible to effectively lock Gryphon up by instructing it to run too many critical jobs leaving absolutely no processor time available for normal operations (including issuing CMD_SCHED_KILL_TX commands) - this is not a fault and is a compelling reason to choose to use the non-critical scheduler where possible. Critical scheduler limitations; Maximum length of any message (including header/id): 288 bytes Maximum number of unique messages used by all critical jobs: 256 Maximum number of messages that can be transmitted in any 1 millisecond time slot (not including normal network limitations): 16 Time that critical scheduler runs into the future: 500 mS (this means it can take up to 3 seconds for CMD_SCHED_KILL_TX to take effect) Note that this used to be 3 seconds prior to Dec 1999 (about), but was reduced to try to reduce the 'delayed kill problem' Estimated accuracy of timings: +/- 5% (actual figures may be altered in future software releases) Known problems: Critical scheduler will stop running after continually running job(s) for about 45 days. In the rare event of Gryphon completely missing a internal interrupt the critical scheduler uses, the critical scheduler may stop running for a fraction of a second. If a network controller goes into a 'bus off' like condition, network may be flooded with the contents of a buffer of up to a hundred critical messages that were scheduled during the 'bus off' condition when the condition is cleared by the user initialising the controller. Typical applications: Normal, non-critical scheduler limitations: Resolution of timings as seen in practice: 3.003 milliseconds Minimum achievable delay (at best): 6 milliseconds - As of April 2000. (Earlier releases have a 10 millisecond resolution and a minimum recommended achievable delay of 20 milliseconds.) Typical applications: