Date: Mon, 30 Oct 1995 11:35:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: terry@lambert.org, rcarter@geli.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: New lmbench available (fwd) Message-ID: <199510301835.LAA06100@phaeton.artisoft.com> In-Reply-To: <199510290258.TAA00620@rah.star-gate.com> from "Amancio Hasty Jr." at Oct 28, 95 07:58:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'd like to see you replicate the buildings only color printer. 8-). > > Thats one scenario the other scenario is in a reasonable small building > when you install a printer you have to go in and dig around with > your configuration files to tell every single workstation where > the freaking thing is or lets say that it goes down and there is > another printer in your vecinity the service should have the > capability to redirect the printing to the next near printer . Ah. This is an issue of offering the printers services to the print queue, where the act of offering the services guarantees the locality. I won't go further into a discussion of NDS vs. X.500; the point is that you will be running an externally inaccessable branch that is tied to physical locality. One could consider this as a sort of "union mount" of a print queue, with a different view on the database by every user. Where the domains overlap (ie: equivalent printers in the same room, etc.), then you can anonymize the queue service. The problem is similar to SMP process scheduling: you would prefer to have the job serviced by the printer "most ready to service the job", which doesn't necessarily mean "most idle", especially if font download or similar time consuming setup is required on one printer, but has already occurred for another. > > A print queue is "a service on a server". > > Should a user really care about the distinction about server or > service . Isn't that what we should try to abstract? No, the user shouldn't care, except to choose their locality on a domain basis. After that, equivalent services are chosen based on increasing locality. Note: "domain" is used in the mathematical sense. > > The distinction is impossible to abstract for physicality. > > Sure however as an architect would you be willing to cripple > your architecture to services which don't require phisicality such > as a printer? You mean, which *do* require physicality? One could consider the same issue: I make a "pizza request" and the nearest "Pizza Hut Delivery" "prints" it for me and delivers it. This is a levelof abstraction above that of a printer, actually, because the delivery removes the locality requirement, once again. > > Ie: I can't afford packet transfer times exceeding my pool retnetion > > time for my video data. > > Hmm... have you heard of RTPv2 with it you can measure bandwith so you > can send out a test stream to measure the bandwith or try to further > encode down the video stream or/an change the frame rate base on the > current bandwith. We got the bits and pieces necessary to implement > what we want . We just don't have the architecture! I think we are at odds here in what we consider the limiting factor for a transaction. I consider it to be the least bounds path from "the best server". #ifdef VIDEO_ON_DEMAND RTPv2 partially solves the problem of determining "the best server", but it overly complicates it be assuming a bandwidth constriction based on oversell and intermediate link congestion. It's arguable that people will accept an effectively random quality deterioration for interavtive communications (after all, that's the basis of "leaky bucket" in ATM), but for things like video delivery systems, that's not acceptable. Note that a "videoconference" is in fact a point-to-point mechanism and thus does not lend itself to replication: I can't get my next 1024 frames from a different Amancio. 8-). The issues addressed by RTPv2 are really too crude, for the most part. If I can't get the same quality as a tape (or better: an LD) from the delivery system, then I might as well stop by Blockbuster (or whatever) on my way home instead of ordering it up through my remote. One of the best statements on video on demand I have ever heard came from Wired magazine: "The only thing stopping video on demand is lack of demand" The only way to cause people to make the jump is to offer better service than the competition, not equivalent service. If anyone ever went into this in a big way, I suspect that this would be at least partially implemented by causing a delay between release to VOD and release to tape, making VOD artificially more attractive. Another part of the equation, which is questionable, is the economy issue. Right now, video stores have to purchase new movies in high quantity sufficient to cause consumers to rent from them rather than the competition, but sufficiently low quantity that they aren't stuck with a massive number of unrentable tapes after a week. This is, in fact, a physically analogous situation to a change in pool retention characterstics. With soft delivery, the restriction on economy of the second-week-selloff partial recovery of investment means that the per unit rental cost to the online "video store" is lower. Which means they can pass the savings onto the consumer (the questionable part: will they do so?) and thus the per unit rental cost can be lower on VOD than on tapes -- making it more attractive. #endif /* VIDEO_ON_DEMAND*/ The consideration here is data delivery and control interaction, not really data delivery and data interaction (that's an interactive communications issue). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510301835.LAA06100>