|
They are all based on internal tcp servers and then use user space direct control of hardware. Simple to implement but flexibility and speed suffer. If your apps are low speed and not complex, its fine From: Michael Schmidt <> To: Cc: tom campbell <> Sent: Monday, October 3, 2011 3:06 PM Subject: [ts-7000] Re: announcing tsctl! On 10/3/2011 6:18 AM, tom campbell wrote:
> Well... count me as an enthusiastic. Glad to hear it! > Read through the web page (which I thought was well written at the right detail level). Seems like an excellent approach. I'm surprised there's not more chatter about the announcement on this group. > > Very, very happy to see Python support. > > A question. Are the canctl, dioctl, and spictl protocols/apis you mention proprietary technology systems protocols/apis? or are they some industry standard? Are they existing now or futures? The canctl, dioctl, and spictl protocols already exist and are implemented in the corresponding utilities by the same name in selected products. The tsctl and logctl protocols are new for tsctl. These protocols were developed by Technologic Systems but are not proprietary in the sense that they are open, documented, and not restricted. If there is interest in any industry standard it could be done, but I doubt it would make much sense in an embedded system to make the effort to have a full-blown CORBA implementation. ;) > When is 7370 targeted? What can I do to make to happen faster? > [...] > What's the license and source availability? Implementing tsctl support for a new platform is fairly straight-forward: determine the object instances needed for the platform, determine how they are related to each other, implement those that are specific to the platform, create any platform specific regression tests, and run all tests applicable to the platform to test. I've passed on your interest in the 7370 to my boss, who ultimately controls the direction of development. Is there any community interest in porting tsctl to other platforms, such as our older products (TS-72XX, TS-73XX, etc.)? We plan to make full source available starting at the first release. I am still pressing the license issue with my boss and would like feedback from you on this as well including any arguments one way or the other that could help me with my case. There will not be any licensing costs involved, but I have been told that the goal is to make the source code available to everyone without restricting our customers to have to release derivative works. To this end, one option under consideration is a dual license where the main license available to everybody would be an open source license such as the GPL with a second license option such as BSD available only for customers who are running the software on one of our products. > Only concern might be speed on some hi bandwidth requirements. I'm sure it will be fine for many applications. This is one area of special interest to me. The canctl core code was significantly rewritten for tsctl. On an otherwise idle TS-4500, the old canctl code could consistently send around 3500 messages per second at 1 Mbps, while the new code can send nearly 6000. (For reference, the theoretical maximum is ~7142, assuming no gap between messages.) While talking directly to the canctl port yields this high performance, using the tsctl port results in lower performance. I believe part of the reason for this is thread switching; if tsctl was to run as a real-time process using SCHED_FIFO I think the performance would be more comparable, but in my experience this also causes severe unresponsiveness. In any case, this is an open area for future improvement if there is demand for it. In most cases, it is expected that the user will use the canctl protocol if they need high performance or backward compatibility, and the tsctl protocol if they want to take advantage of the new features and flexibility. > I would suspect that many applications would need to bypass at least the IP layer and/or server side "locking". If there is no contention, locking is fairly low overhead. We are using pthread mutexes which are very fast if there is no contention. There is a bit of overhead on top of this to implement our locking model which prevents deadlocks in some situations, but again, if there is no contention this should be fairly fast. One nice thing about the Python interface is the ease with which it is possible to set up tests to measure such things. > To that end I suggest that the server side api to the hardware be "clean" so a user program could talk directly to that api to the hardware (bypassing IP layer). Maybe incorporate a mechanism in protocol to tell tsctl that it can't use subsystem xyz because user is talking to it directly. The design philosophy looks like you might have addressed this. Yes, there is a kind of layered approach to achieving higher performance as it is needed, at the expense of less flexibility. At the top end, the easiest way to get performance is to identify where the bottleneck are, and implement new classes or API functions as needed to get around the bottleneck. Already the Bus class contains examples of this: it implements functions for setting, clearing, assigning, and toggling bits in a single command, to avoid the need to perform read/modify/write cycles across the network. And while for small tasks it can be useful to directly access the bus across the network, for more complex tasks other classes use the bus directly on the server. If this is insufficient, a more specialized and low-level solution would be to implement an application that directly uses the C API on direct (non-network) objects like the server does, and not implement the network functionality at all. At the bottom end, a developer who requires the absolute maximum performance could use the object API as a shortcut to avoid needing to look up registers in the datasheet, and could instantiate each class inline to avoid object call overhead. This has the potential to be a quite involved procedure, as basically it is a transform on each object into separate source code with hard-coded functions for each instance. > I couldn't tell in a quick read whether you were doing UDP or TCP. I'd support both. The UDP for speed when it's from process to process inside the cpu. The TCP for reliability when it's off chip. Like from the laptop in my office over a satellite link to 7370 in the middle of the ocean. If I had to choose which to do first, I'll probably pick UDP, but I would make sure there is an upgrade path in the API to TCP (or maybe some of the unix internal queues/shared memory for more maybe more speed) which would allow you to implement other transport mechanisms in future without breaking UDP code in the field. We only support TCP, which was a design choice which predates my involvement in ctl development. It might be interesting if someone is interested in creating a server thread to handle some UDP requests to see what the performance difference is. > Looking forward to seeing the code and trying it. Will you make announcements to this group at signficant release points? Yes, definitely. ______ Best Regards, |__ __/ Michael Schmidt || Software Engineer ||echnologic Systems (EmbeddedARM.com) || (480) 16525 East Laser Drive |/ 837-5200 Fountain Hills, AZ 85268 http://oz.embeddedarm.com/~michael __._,_.___
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: =Email Delivery: Digest | m("yahoogroups.com?subject","ts-7000-fullfeatured");=Change Delivery Format: Fully Featured">Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | =Unsubscribe __,_._,___ |