Great! Now we can all go back to sleep.
Per
Peter Graf writes:
> a happy new year 2003!
Thanks - and the same to you and other list members!
> An issue regarding re-scheduling of jobs under QDOS/SMS:
>
> As far as I remember, the job scheduler is triggered only if:
> (A) It is called directly from the frame interrupt about every 20 milis
Peter Graf writes:
<>
> Hm. I know this is perfectly allright, and I think I even understand the
> priciples of background device drivers a bit.
Oops. Should have known ;) However, sometimes the obvious is missed even by
experts, so its good to get this out of the way first.
> The issue I'm dea
Phoebus Dokos writes:
>
> >I see only two possible solutions for QDOS/SMS:
> >
> >(1) A higher rate for the frame intterrupt (disadvantage: higher system
load)
> >
>
> This would be feasible I think without too much problems for the system.
Not really a good idea, I think. As Peter demonstrates
Peter Graf writes:
>>>An issue regarding re-scheduling of jobs under QDOS/SMS:
>>>
>>>As far as I remember, the job scheduler is triggered only if:
>>>(A) It is called directly from the frame interrupt about every 20
milisec.
>>>or
>>>(B) After certain non-atomic traps that can be called from use
Richard Zidlicky writes:
> > >For me this means that I will wait for a fix of the OS
> > >before I care about writing a clean driver with ISR for
> > >ethernet. After the OS has been fixed: Wether the ISR will
> > >actually fill any RAM buffers or just wakes up a usermode
> > >job that reads from
Richard Zidlicky writes:
> > > > # He can request a re-schedule simply by setting the sys_rshd system
> > > > # variable to $FF. This will then be checked every time an SMSQ trap
is
> > > > # invoked, which should normally happen very often. I think this
should
> > > > # be good enough for his pr
BRANE writes:
> > Or as Zeljko suggested a Crusoe (which is not crap) :-)
> > However because of their NDAs, binding agreements etc. it's out of the
> > question too.
>
> I don't like Transmeta. Very closed design.
>
> > Another VERY good idea is the PowerPC (especially the new offerings from
>
Richard Zidlicky writes:
<>
> > Plus, I'm a bit surprised that you are apparently using jobs to fetch
the
> > data from the ethernet card... It should be done via an interrupt
handler
> > instead... Actually, the best design would be to have the Q60 fast
interrupt
> > handler to fill a buffer, an
Peter Graf writes:
> Hi Per,
>
> >And Peter, did you try out the suggestions that were made at that time?
>
> Can you be a bit more specific? I remember only one applicable suggestion,
> which was to set a system variable before leaving the ISR. Didn't work, at
> least not under QDOS.
# By exiti
Peter Graf writes:
> >Yes, this I know, thanks... I'm perfectly aware of the fragmentation and
of
> >out of order receipt of TCP packets... That doesn't change the fact you
could
> >use the fast interrupt to store as many TCP packet as needed (i.e. when
they
> >come in), into a buffer (organized
Peter writes:
<>
> > Arent you trying to make the OS do something it was never designed to
> > do? Writing drivers is a programming challenge. The OS is there to help
> > where it can, but no OS author can anticipate any and every piece of
> > hardware that is going to be attached to the machine
Richard,
Some time ago you asked me to look into a bug in the tk2 clone by HPR(?) but
I didnt have much success. Could you please tell me the status of that code.
Is it PD? Would it be ok for me to pass the source on to someone who might
be able to fix it?
Per
Peter Graf writes:
> I had saved a HTML page from Hans-Peter Recktenwald about
> his T6 software half a decade ago, it says:
<>
Thanks for the info. Its been such a long time, Id even forgotten the name
of the toolkit. Now its all coming back to me. Is h-peter recktenwald still
active on the QL
14 matches
Mail list logo
