1 / 14

3.14 Work List

3.14 Work List. IOC Core Channel Access. Changes to IOC Core. Online add/delete of record instances Tool to support online add/delete OS independent layer to support port of IOC Core Revisit time stamp library Redundancy Standard set of statistics available through pseudo-channels

arlenecyr
Download Presentation

3.14 Work List

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 3.14 Work List IOC Core Channel Access

  2. Changes to IOC Core • Online add/delete of record instances • Tool to support online add/delete • OS independent layer to support port of IOC Core • Revisit time stamp library • Redundancy • Standard set of statistics available through pseudo-channels • Log writes to database fields • Use priority in scan tasks differently • Frequency-based monitor notification • Port database to the portable server • Improve array handling capabilities • ANSI-fy src/drv/old - drivers Put off until later…….. • Extensible link type definition - 4.0 • Adding record, device, driver support

  3. Changes to IOC Core - Online Add/Delete • Changeable links was the first part of the task and was completed in 3.13 • dynamic lockset computation taken from IOC init and done dynamically • Downloading record instances during operation will need to be supported • IOC initialization has to be broken up and called at any time • record initialization must be possible at any time during operation • device initialization and driver initialization must be possible at any time • modifications may need to be made for all device and driver support

  4. Changes to IOC Core - tools to support add/delete • Is the request to load new records initiated in the host or the target? • Will we use dbLoadRecords or a network protocol to accomplish this? • How closely integrated will this be with the existing configuration tools? • CAPFAST • GDCT • DCT • Relational and OO databases • ASCII (AWK/PERL/VI)

  5. Changes to IOC Core - OS independent layer • Operating system services needing a compatibility layer • SymFindByName • Semaphores • Task Create • Interrupt Services • Timer management • Bus to local addresses • Sockets • Create list of services needed - partial list above • Put the existing ones in the source release control for common use • Document the compatibility layer

  6. Changes to IOC Core - Revisit Time Stamp Library • Use UNIX time stamp format • Use the standard UNIX routines for time in place of the existing time stamp library • Verify the year 2000 is no problem • Resolve a newly discovered time stamp issue at TJNAF

  7. Changes to IOC Core - Redundancy • All database record types? • State notation language • Which drivers can handle redundant hardware? • How do you mix redundant and non-redundant hardware capability • Recreate it - merge Tate changes • Is this required by anyone?

  8. Changes to IOC Core - Statistics from IOC • CPU utilization • Memory utilization • Stack usage • Critical task state of health • running/suspended/etc… • periodicity of scan tasks - do they start on time • number of records processed by each scan task • CPU utilization per task

  9. Changes to IOC Core - Logging Database Writes • Uses of write logging • discover unexpected access to a record • use the log as a playback script complete with delay/value information • Logging done at the channel access write level • Ability to log writes to a database enabled on a record by record basis • Integrate the logging into a tool that allows callable access

  10. Changes to IOC Core - Task Priorities • Currently scan tasks are given tasks priorities: ioevent high, ioevent med, ioevent low, .1 sec high, .1secmed. .10 sec low, channel acc. • New scheme would allow setting the relative priorities of scan tasks amongst themselves and in relationship with the channel access server. NOTE: channel access buffering is a side affect of having a lower priority than scanning • Several priorities will be reserved above channel access to continue the current relationship between scan tasks and channel access. • Several priorities will be reserved where the channel access client and the scan tasks can be interleaved to provide more suitable environment for closed-loop control over the network and a more controlled degradation mode.

  11. Changes to IOC Core - Frequency Based Monitors • Add two notification methods: minimum interval and regular interval • Minimum interval would check only when the record is being processed. Notification is sent when the specified time has expired - this is inline code for record processing. • Regular interval monitors would send values regardless of record processing • a new thread would be needed to service these • synchronizing with record processing is important for time stamp alignment

  12. Channel Access Modifications - V3 w/Old Server • 1 dimensional big arrays supported • name caching / alternate name services in the client • coalesce multiple requests for a single channel to one request to the IOC • use a common data object for the gateway and CDEV (merge the functionality of CDEV Data and GDD)

  13. Channel Access Modifications - V3 w/Portable Server (3.14 or later) • Put the new server in the IOC • Revise CA buffering so that 32K is not used - it becomes configurable • Control over monitor engine - rate limit, queue length limit, independent deadband, trigger from an alternate channel • JAVA client • Multipriority client connections to the server • Export transaction semantics to the client • Client conversions in the client • Special server library for exporting C variables (no database needed) • Pseudo channels to make server statistics available • Hooks to log all writes (specified in access control) • C++ API for client - review interface to CDEV as part of design • Review portable server doc’s

  14. Channel Access Modifications - V4 • Compress the protocol - header, data, alignment • Multi-dimensional array support • User defined containers exported to the client API • User defined application types to the client API • User defined event types to the client API

More Related