On 16 Jan 2013, at 17:42, Dennis Boone <drb at msu.edu> wrote:
It'd get messy with drilling holes and running it through walls and
whatnot, but I know it'd be the best.
Cheating is fair. :) In or next to ventilation ducts, next to radiator
pipes, under baseboards, through the floor in the back corner of closet,
etc. can work, with proper attention to the details.
I do that for room-to-room but it'd get messy with me lacking the skills to make the cables myself (due to eyesight) and having to go from upstairs all the way to the basement. One floor would be easy.
I suppose I could always run the cable around the outside of the house ;)
De
I have a similar situation with my garage - my DEC collection lives in the garage, but the Internet connection is in the main house. At the moment, the problem is solved with an Apple Airport in the main house and an Aiport Express in bridge mode in the garage. Unfortunately, this isn't as reliable as I had hoped - I get quite a few dropped packets. I was considering the powerline option. 50Mbps isn't a problem considering the majority of the DEC stuff is 10Mbps half duplex :)
Ian
On 2013-01-16, at 2:38 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 16 Jan 2013, at 17:37, Dennis Boone <drb at msu.edu> wrote:
Running cables all the way from the second floor isn't viable.
"Not viable to run cable" usually comes down to "too lazy". Not
throwing stones: I've been lazy about cabling too. But you might
consider bouncing the particulars off of the crowd to see if there are
any suggestions for overcoming the obstacles. Wired really is the most
stable and reliable, for all the wireless hoopla these days.
It'd get messy with drilling holes and running it through walls and whatnot, but I know it'd be the best.
De
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=8D8D5FDC602D11E29…
On 16 Jan 2013, at 17:37, Dennis Boone <drb at msu.edu> wrote:
Running cables all the way from the second floor isn't viable.
"Not viable to run cable" usually comes down to "too lazy". Not
throwing stones: I've been lazy about cabling too. But you might
consider bouncing the particulars off of the crowd to see if there are
any suggestions for overcoming the obstacles. Wired really is the most
stable and reliable, for all the wireless hoopla these days.
It'd get messy with drilling holes and running it through walls and whatnot, but I know it'd be the best.
De
Running cables all the way from the second floor isn't viable.
"Not viable to run cable" usually comes down to "too lazy". Not
throwing stones: I've been lazy about cabling too. But you might
consider bouncing the particulars off of the crowd to see if there are
any suggestions for overcoming the obstacles. Wired really is the most
stable and reliable, for all the wireless hoopla these days.
De
On 16 Jan 2013, at 17:29, hvlems at zonnet.nl wrote:
Ethernet over mainspower runs at 50 Mb/s (a friend uses such a product). It is reliable but both rooms are on the same phase.
Wireless is your best bet. Two accesspoints in "remote bridge mode" ought to do the job.
If all else fails run ethernet over a phone line, 10 Mb/s is feasible depending on distance.
Any suggestions for access point models? I need one that doesn't suck if I go that approach.
------Origineel bericht------
Van: Cory Smelosky
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] Multi-floor household (DECnet) routing help needed
Verzonden: 16 januari 2013 23:12
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Jan 15, 2013, at 10:22 PM, Gregg Levine wrote:
On Tue, Jan 15, 2013 at 11:00 AM, <Paul_Koning at dell.com> wrote:
...
Focal, Coral, Jovial (gag), Mumps. Then from the outside world: Algol-60, Algol-68,...
Hello!
What's wrong with Jovial? We've built a great air traffic control
system around it. Too bad the hardware is old enough to vote.
The designer clearly demonstrated that he has few brain cells and none of them contain any knowledge about structured programming languages or for that matter any of the design principles that make Algol-60 what it is.
I don't remember enough of the details, but that much was immediately obvious by inspection, and my conclusion was that I know all I need to know and I will never look for more.
paul
Ethernet over mainspower runs at 50 Mb/s (a friend uses such a product). It is reliable but both rooms are on the same phase.
Wireless is your best bet. Two accesspoints in "remote bridge mode" ought to do the job.
If all else fails run ethernet over a phone line, 10 Mb/s is feasible depending on distance.
------Origineel bericht------
Van: Cory Smelosky
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] Multi-floor household (DECnet) routing help needed
Verzonden: 16 januari 2013 23:12
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Jan 15, 2013, at 9:09 PM, Jordi Guillaumes i Pons wrote:
El 15/01/2013, a les 17:56, Johnny Billquist <bqt at softjar.se> va escriure:
That it would... Anyone have GCC setup to generate something that can be linked under RSX?
Can't do that. But I'd bet it can generate code that can be linked under BSD2.11
(BTW the bug I found in the PDP-11 gas assembler is still there)
BSD support was removed from GCC, but I would think it could be put back.
Generating code that can link under RSX probably amounts to writing a libc for RSX, then (for now) tweaking the generated assembly code and assembling/linking under RSX. I haven't tried that, but I was planning to do that with RSTS (I'm hoping to use an existing DECNA driver written in C as the basis for one for RSTS).
I have a "bare metal simh" hacked up newlib, just good enough to run the execution tests of the GCC test suite.
Right now the main issue seems to be that some floating point code kills the compiler. I've tried for a long time to get it to deal correctly with ac4/ac5 which can't directly load/store to memory, and haven't succeeded yet. It's supposed to be possible. I may end up disabling those two registers for now.
paul
On Jan 16, 2013, at 5:21 PM, <Paul_Koning at Dell.com>
wrote:
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
On 15 Jan 2013, at 20:25, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 15/01/2013, a les 20:27, Paul_Koning at Dell.com va escriure:
When I build it with the default build settings (async I/O enabled) both PDP11 and VAX hang at boot. Built with NOASYNCH and it runs fine. I haven't tried other platforms.
I have. Mark is working on the hang issues. He has fixed some of the bugs, but that asynch code seems to be specially hard to debug. BTW it is a multicore-multiprocessor issue also observed in other operating systems.
I'm curious if anyone else has tried it, or has ideas of what's wrong here. When it gets in this state, I have to kill the process; it won't answer interrupts or even SIGTERM.
I run it with asynch disabled for the time being.
When I try that, it fails to link.
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_todr_wr in ccGqWyaE.o
_todr_resync in ccGqWyaE.o
_todr_rd in ccGqWyaE.o
ld: symbol(s) not found for architecture x86_64
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
I should have just looked it up first rather than answering from memory. Here is the fix:
diff --git a/sim_timer.c b/sim_timer.c
index 6044643..8c1e9e7 100644
--- a/sim_timer.c
+++ b/sim_timer.c
@@ -402,7 +402,7 @@ if (tim > SIM_IDLE_MAX)
tim = 0;
return tim;
}
-#if !defined(_POSIX_SOURCE) && defined(SIM_ASYNCH_IO)
+#if !defined(_POSIX_SOURCE)
#ifdef NEED_CLOCK_GETTIME
typedef int clockid_t;
int clock_gettime(clockid_t clk_id, struct timespec *tp)
paul
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
On 15 Jan 2013, at 20:25, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 15/01/2013, a les 20:27, Paul_Koning at Dell.com va escriure:
When I build it with the default build settings (async I/O enabled) both PDP11 and VAX hang at boot. Built with NOASYNCH and it runs fine. I haven't tried other platforms.
I have. Mark is working on the hang issues. He has fixed some of the bugs, but that asynch code seems to be specially hard to debug. BTW it is a multicore-multiprocessor issue also observed in other operating systems.
I'm curious if anyone else has tried it, or has ideas of what's wrong here. When it gets in this state, I have to kill the process; it won't answer interrupts or even SIGTERM.
I run it with asynch disabled for the time being.
When I try that, it fails to link.
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_todr_wr in ccGqWyaE.o
_todr_resync in ccGqWyaE.o
_todr_rd in ccGqWyaE.o
ld: symbol(s) not found for architecture x86_64
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
