From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 01:51:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C530416A4CF for ; Sat, 21 May 2005 01:51:10 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3713643D6D for ; Sat, 21 May 2005 01:51:09 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 9733 invoked from network); 21 May 2005 03:51:07 +0200 Received: from p508fb9b4.dip.t-dialin.net (HELO localhost.skatecity) (80.143.185.180) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 21 May 2005 03:51:07 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4L1p54M009234 for ; Sat, 21 May 2005 03:51:05 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4L1p5WS009233; Sat, 21 May 2005 03:51:05 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sat, 21 May 2005 03:51:05 +0200 To: freebsd-hackers@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050521015105.GA9063@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520230845.GC51092@dan.emsphone.com> Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 01:51:10 -0000 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.