SGI: Development

Just for teh lulz:

http://www.faktor0.de/sslow.gz
(single executable file compressed with gzip)

To start the program:
gunzip sslow.gz
chmod 755 sslow
./sslow

------------------------------------------------------

Required Nekoware SDL packages
(same as for "thieves"):

neko_sdl-1.2.13.tardist
neko_libiconv-1.11.tardist
neko_expat-2005-01-28.tardist
neko_gettext-0.17.tardist
neko_glib-2.12.13.tardist
neko_libcroco-0.6.1.tardist
neko_libxml2-2.6.27.tardist
neko_zlib-1.2.3-r1.tardist
neko_ncurses-5.7.tardist
neko_readline-4.3.tardist

Very cool! Is the source code available by any chance? :]

Looks cool. Can't wait to try it.

again: fine piece of work!

Not yet. I have to clean up the code before I show it to the public.

I keep the door to my bedroom closed, too

On the Onxy with default gamma, the spheres are a bit too white. Is there a command-line option for gamma correction?

Also, have you thought of submitting this to Xscreensaver?

You're right!
I must add some commandline-options. If I can manage it, I do an update this weekend.



No. But thank you for the hint!

A nekoware-style tardist.

Unfortunatelly, the SGI implementation of SDL does not support SDL_SetGamma.

But you can change the size and the number of the spheres now with two new
commandline-options:


Example: ./sslow -num 16 -size 0.5

The new executable is here:
http://www.faktor0.de/sslow.gz

There is also a soundtrack for the program to get you into the right mood:
http://www.faktor0.de/music/slow_spheres.mp3
(ca 15 minutes of ambient noise, size = 14MB)

Wow, thanks!

Since I never learned how to make a tardist, I am happy if somebody is doing it!

The required bits to re-generate a new tardist are part of the archive itself in the opt.dist component. You could either use the swpkg tool for a nice GUI to package editing and generation, or edit the .idb to add/remove files or change their location, or the .spec to change versions, dependencies, package names and descriptions. If you want to start from scratch, a number of scripts have been posted here to automate package generation, my attempt is attached to a thread discussing pixie.

Newbie question: could it be used as a screen saver on my SGI ?

Hey everyone

i saw the screenshot and thought why not try that on my O2 R5200 300 mhz

i installed all the parts and ran it
hoever i then get this

Trace/BPT/RangeErr/divZero/Ovflow trap (core dumped)

Any ideer what thats all about or some way i can solve it so i can check it out ?


best reguards

mis

That's usually an indication you're trying to run software compiled on 6.5.21+ on a a lesser version.

TCP/Ethereal puzzle...

I have two boxes, 10.0.0.10 [Irix 6.5.30] and 10.0.0.20 [Irix 6.5.22], on the
same local wire [connected via a switch]; both of them have fired up Ethereal
0.9.2 [from the SGI Freeware November 2002 CDs].

Now, on 10.0.0.20 I issue <telnet 10.0.0.10 discard>, and immediately after the
established connection, I escape and quit. As is well known, this sequence
creates 7 frames. However, looking just at the resulting three-hand handshake,
what I don't understand is the second frame [10.0.0.10 > 10.0.0.20]:

Second frame in Ethereal on 10.0.0.20:
.
.
Transmission Control Protocol [ignore Ports/Seq/Ack]:
.
.
Checksum: 0x09c5 (correct)

Second frame in Ethereal on 10.0.0.10:
.
.
Transmission Control Protocol [ignore Ports/Seq/Ack]:
.
.
Checksum: 0x8841 (incorrect, should be 0x09c5)

Any explanation regarding the conflicting checksums?

Hi,

Well lets start by saying no magic bullets on this one.

I am assuming that you are doing this because you suspect a problem not just for the fun of it?

If this is right then you may have the cause (or symptom) of your problem.

I assume that you have replaced cables and hub/switch and rerun the test - do you get the same result.

Could be a back network interface.

The checksum will normally indicate a problem either with hardware or software and assuming that you are software homogeneous we would expect no error due to bad tcp checksum creation.

Also your post is quite technical in nature and your description a little brief.

Can we step back a moment and get a description of the setup and scenario along with motivation for using ethereal to look at this.

I must say that I only ever used tcpdump when I was simulating satellite delay effects on tcp algorithms but anyhow.

Have you considered plugging a linux box into the network and doing your analysis on all data flow from a third machine to observe traffic to verify this finding?

Cheers

I would agree with the third machine assessment - at least on Linux, it's impossible to really tell if your TCP checksumming is correct locally because checksumming can be offloaded into the driver/card if they support it. Try firing up Ethereal/Wireshark on a Linux box with any of the Intel PRO networking adapters and you'll see what I mean - it'll say all locally sent packets have incorrect checksums even when they don't on the wire.
So get a third system in the mix and you can see exactly what the two machines are sending each other over the wire, rather than what they *think* they're sending each other from userspace.

Hi again,

I would take a conservative engineering approach to this. Given that we do not know if it is a cabling, hub/switch, network card or software issue I would try to get a third machine in there to look at things to confirm your findings.

So we have a problem of communication between A talking to B, or A <-> B.

Are you running ethereal on A or B. If you are running etherreal on A and A has a bad card or cable then ehterreal could be subject to errors also and so is incorrectly reporting problems but those that are not with the source.

I would do the following.

I would place a third machine into the mix and try to recreate the test scenario that does not have the error.

At that point you will have a functioning network.

Then work forwards in order to recreate the error. That is to say that you should introduce components one at a time and test to validate in order to recreate the error. The point at which the error occurs indicates that the last introduced component is at fault.

I know that this might seem all a bit obvious and it is not guaranteed to work but I think that it is a good approach that will probably help.

Cheers

I would like to discount some of the cabling issues, ethernet frames are covered by CRC so a packet should only be received by the protocol stack if the CRC is correct, the IP checksum only covers the IP header part of the IP datagram. I would suggest that if a checksum is wrong it is because it was incorrectly calculated at source, or incorrectly modified ( or failed to be modified ) en-route when the TTL was decremented, or incorrectly validated.