Announcement

Collapse
No announcement yet.

Q? about command line switches. (Maggi?)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Q? about command line switches. (Maggi?)

    I went back through and looked at that optimizations thread and was trying to figure out how exactly Maggi set the batch file up. I've figured out the first batch file, but the send results batch file has me a little confused. What I want to know is what the -stop_after_xfer option does. Now presumably it uploads the result file, but what happens next. Does it download a new WU, or is that where it stops.
    What I'm trying to figure out is how to replenish the work units. It looks like what happens is that you go through and proccess all of the the units without uploading them, and then you run the next batch, which uploads them. Then what?

    Help would be much appreciated, thanks all.
    Ian
    Primary System:
    MSI 745 Ultra, AMD 2400+ XP, 1024 MB Crucial PC2100 DDR SDRAM, Sapphire Radeon 9800 Pro, 3Com 3c905C NIC,
    120GB Seagate UDMA 100 HD, 60 GB Seagate UDMA 100 HD, Pioneer DVD 105S, BenQ 12x24x40 CDRW, SB Audigy OEM,
    Win XP, MS Intellimouse Optical, 17" Mag 720v2
    Seccondary System:
    Epox 7KXA BIOS 5/22, Athlon 650, 512 MB Crucial 7E PC133 SDRAM, Hercules Prophet 4500 Kyro II, SBLive Value,
    3Com 3c905B-TX NIC, 40 GB IBM UDMA 100 HD, 45X Acer CD-ROM,
    Win XP, MS Wheel Mouse Optical, 15" POS Monitor
    Tertiary system
    Offbrand PII Mobo, PII 350, 256MB PC100 SDRAM, 15GB UDMA66 7200RPM Maxtor HD, USRobotics 10/100 NIC, RedHat Linux 8.0
    Camera: Canon 10D DSLR, Canon 100-400L f4.5-5.6 IS USM, Canon 100 Macro USM Canon 28-135 f3.5-5.6 IS USM, Canon Speedlite 200E, tripod, bag, etc.

    "Any sufficiently advanced technology will be indistinguishable from magic." --Arthur C. Clarke

  • #2
    The -stop_after_xfer option uploads your completed work unit and then downloads a new one. It then stops.
    A few computers, some with Matrox stuff...I'll add details later.

    Comment


    • #3
      Thats exactly what I wanted to know.

      Thanks much Charles!
      Primary System:
      MSI 745 Ultra, AMD 2400+ XP, 1024 MB Crucial PC2100 DDR SDRAM, Sapphire Radeon 9800 Pro, 3Com 3c905C NIC,
      120GB Seagate UDMA 100 HD, 60 GB Seagate UDMA 100 HD, Pioneer DVD 105S, BenQ 12x24x40 CDRW, SB Audigy OEM,
      Win XP, MS Intellimouse Optical, 17" Mag 720v2
      Seccondary System:
      Epox 7KXA BIOS 5/22, Athlon 650, 512 MB Crucial 7E PC133 SDRAM, Hercules Prophet 4500 Kyro II, SBLive Value,
      3Com 3c905B-TX NIC, 40 GB IBM UDMA 100 HD, 45X Acer CD-ROM,
      Win XP, MS Wheel Mouse Optical, 15" POS Monitor
      Tertiary system
      Offbrand PII Mobo, PII 350, 256MB PC100 SDRAM, 15GB UDMA66 7200RPM Maxtor HD, USRobotics 10/100 NIC, RedHat Linux 8.0
      Camera: Canon 10D DSLR, Canon 100-400L f4.5-5.6 IS USM, Canon 100 Macro USM Canon 28-135 f3.5-5.6 IS USM, Canon Speedlite 200E, tripod, bag, etc.

      "Any sufficiently advanced technology will be indistinguishable from magic." --Arthur C. Clarke

      Comment


      • #4
        The way my batch files work, is that the first is running with the -stop_after_process switch and then changing to the next dir, from 1 to 25.
        The second, which uploads the units, starts with the dir before the current and then runs backwards through the dirs uploading until I stop it, this way it doesn't have to run through a lot of dirs without WUs to refresh.
        "That's right fool! Now I'm a flying talking donkey!"

        P4 2.66, 512 mb PC2700, ATI Radeon 9000, Seagate Barracude IV 80 gb, Acer Al 732 17" TFT

        Comment


        • #5
          yup ...

          and to work around a bug in SETI, when you're continously online you should split your batch to

          seti.exe -stop_after_process
          seti.exe -stop_after_xfer

          because then it'll be restarted for each WU and won't cause a resource hog.

          Cheers,
          Maggi
          Despite my nickname causing confusion, I am not female ...

          ASRock Fatal1ty X79 Professional
          Intel Core i7-3930K@4.3GHz
          be quiet! Dark Rock Pro 2
          4x 8GB G.Skill TridentX PC3-19200U@CR1
          2x MSI N670GTX PE OC (SLI)
          OCZ Vertex 4 256GB
          4x2TB Seagate Barracuda Green 5900.3 (2x4TB RAID0)
          Super Flower Golden Green Modular 800W
          Nanoxia Deep Silence 1
          LG BH10LS38
          LG DM2752D 27" 3D

          Comment


          • #6
            Maggi, if I understand you correctly, you will use only one batch-file with both -stop_... after each other then you're always connected. I can't see any reason for this, but then again if I dig out my win9x-copy, it doesn't run the cmd-line so I can't check out the resource-bug.

            First, two facts:

            -stop_after_xfer stops after uploading result/getting new wu.

            -stop_after_process processes already downloaded unit, and stops. BUT if the wu is already done or there isn't any wu, seti@home tries to connect and upload the result/gets new unit.

            The main reasons to use batch-files is:
            1: cache units if you're not always connected.
            2: cache units for future connecting problems.

            As a measure against 2, I would still use two batch-files, even if I was always connected.
            If you're never with the machine, you can just set the last line in process.bat to start upload.bat, and the opposite in upload.bat.

            If you don't want to cache units, but wants to circumvent the resource-bug you can:
            3: Use only -stop_after_process in a bat-file, or
            4: Use SetiLog, or
            5: Don't use win9x.

            Comment


            • #7
              Ok, maybe I wasn't very clear ...

              At work I use a double P3 running WinNT and being connected to the net 24/7.
              Upon startup I launch two batches for SETI which do the following:

              Code:
              :seti_render
              
              Seti.exe -stop_after_process
              Seti.exe -stop_after_xfer
              
              goto seti_render
              Before I knew about the resource hog, it looked like this:

              Code:
              :seti_render
              
              Seti.exe
              
              goto seti_render
              The latter would restart SETI only if some error occured and thus would probably run for weeks and hence slowdown the system (because of the goto-loop). The version I posted first will guarantee two restarts of SETI for every WU and hence would not cause slowdowns while crunching.

              At hime I run the CMD line version under W98 and generated a script for caching and crunching 20 WUs in a row...

              for rendering:
              Code:
              cd .\Kopie(01)
              Seti.exe -stop_after_process
              cd ..
              
              [...]
              
              cd .\Kopie(20)
              Seti.exe -stop_after_process
              cd ..
              for sending/recieving:
              Code:
              cd .\Kopie(01)
              Seti.exe -stop_after_xfer
              cd ..
              
              [...]
              
              cd .\Kopie(20)
              Seti.exe -stop_after_xfer
              cd ..


              Hope this clears up the confusion.

              Cheers,
              Maggi

              [This message has been edited by Maggi@Home (edited 17 June 2000).]
              Despite my nickname causing confusion, I am not female ...

              ASRock Fatal1ty X79 Professional
              Intel Core i7-3930K@4.3GHz
              be quiet! Dark Rock Pro 2
              4x 8GB G.Skill TridentX PC3-19200U@CR1
              2x MSI N670GTX PE OC (SLI)
              OCZ Vertex 4 256GB
              4x2TB Seagate Barracuda Green 5900.3 (2x4TB RAID0)
              Super Flower Golden Green Modular 800W
              Nanoxia Deep Silence 1
              LG BH10LS38
              LG DM2752D 27" 3D

              Comment

              Working...
              X