Date: Sat, 21 May 2005 03:51:05 +0200 From: alexander <arundel@h3c.de> To: freebsd-hackers@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. Message-ID: <20050521015105.GA9063@skatecity> In-Reply-To: <20050520230845.GC51092@dan.emsphone.com> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri May 20 05, Dan Nelson wrote: > > How often are you doing this? I wrote a quick microbenchmark and my > pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde". I > don't think that's your bottleneck. If it is, the usual solution is to > not do a write on every iteration. You've got a (maximum) 100hz screen > refresh rate anyhow, so doing more than 100 updates per second won't do > you any good. Even 10 is probably more than you need. > > -- > Dan Nelson > dnelson@allantgroup.com Ohh...sorry for not telling you this. Yes. The app works alright when executed from the console. But my problem is with xterm or Eterm. They don't handle VT100 very well. I've added a nanosleep after each VT100 output but that didn't solve the issue. In fact Eterm or xterm might not update the value for as long as 5-8 seconds. I tested burncd's code and it uses fprintf to update the bytes it sends. And that works perfectly under Eterm and xterm. The app needs to handle at least 40000h updates in 10 seconds. But as you said I can break that down to ~ 100 updates per second. However I don't think that that's going to do much of a different with the delays I'm experiencing under Eterm/xterm. The app is used to upload data to another device. Under the console the upload time is ~ 11.5 seconds. Under Eterm it is ~ 25 seconds. That's why I really want to get rid of the VT100 stuff. The nanosleep delay I'm using is 0,00050000. I also disabled all the nanosleep syscalls, but Eterm/xterm still lags awfully. Plus the cursor jumps forth and back. Cheers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050521015105.GA9063>