Order

Overview

Order is data set that includes request to rent or sell specific computing resources. Order is a placed offer on the Marketplace:

  • by Supplier to rent resources - ASK order,
  • by Customer to buy resources - BID order.

Supplier creates ASK orders not directly but only configuring ASK plans. Now this function is available in SONM CLI. Customer creates BID orders directly. Now this function is available in SONM CLI. Further will be described the BID order. To get information about ASK plan and ASK order please go to the ASK plan page.

To start working in Sonm as a Customer your should install the appropriate Sonm components (CLI, Node) (how to do that).

BID order creation

To place your new BID order on Sonm Marketplace follow the steps below.

  1. Open cmd and start the Sonm components (after installation they are started automatically):
    • sudo service sonm-node start
    • sudo service sonm-cli start
  2. Create a blank text file in your home directory and name it as <yourbid>.yaml, for example, bid.yaml.
  3. Open file to edit: sudo nano bid.yaml
  4. Fill the file with the parameters of rent and hardware needed that described below.
  5. Save and close the file.
  6. Place your BID order to Sonm Marketplace: sonmcli order create <yourbid>.yaml. You will get the order ID as an answer.

See the full Sonm CLI Guide here.

Note that the Customer also can buy resources without placing BID orders but using quick-buy function. See the Sonm CLI Guide and Sonm Market Guide.

BID order parameters

BID order is characterized by the following parameters:

  • duration - duratation of the rent in format of XhYmZs, for example: 12h23h45s. If the duration is 0, the deal will be spot, else forward.
  • price - order rent price in USD/h or USD/s, for example: 4.23 USD/h.
  • order type - order type: BID. The value appears automatically after creation.
  • creator - creator's Ethereum address. The value appears automatically after creation.
  • counterparty - counterparty's Ethereum address. Is optional, restricts buying resources only from specified address. Allways use copy-paste to set this value.
  • blacklist - additional blacklist to be used; set Etehreum address of blacklist owner.
  • identity - minimal [identity level]() of counterparty: anonymous, registered, identified, professional.
  • tag - an arbitrary string tag for the order. BID order tag will be available in the deal.
  • resources:
    • network:
      • overlay - indicates whether overlay networking is required: true or false.
      • outbound - indicates whether outbound connections are required (internet access): true or false.
      • incoming - indicates whether inbound connections are required and public IP should be present on worker: true or false.
    • benchmarks - required values of the resources benchmarks:
      • cpu-cores - required CPU cores. This only specifies mininum number of CPU threads, not their scheduling. Can be fractional, for example: 3.5. To specify amount of computing power use cpu-sysbench- parameters.
      • cpu-sysbench-one - minimum computing power of single CPU thread, calculated via sysbench (some abstract value, currently it is how many times CPU can calculate first 50000 prime numbers in 10 seconds), for example: 1528.
      • cpu-sysbench-multi - the same as above, but for all threads, can be less than cpu-sysbench-single when you need less than 1 core, for example: 5677. Can be less than cpu-sysbench-single when you need less than 1 core.
      • ram-size - required RAM size in bytes, for example: 2000000000.
      • storage-size - required storage size in bytes, for example: 500000000. Note that if the parameter is not specified, then the minimum value in 64Mb is still allocated.
      • net-download - download throughput in bits/s, for example: 25000.
      • net-upload - upload throughput in bits/s, for example: 40000.
      • gpu-count - minimum number of GPU (1 for each GPU), for example: 2.
      • gpu-mem - minimum memory for single GPU in bytes, for example: 4096000000.
      • gpu-eth-hashrate - total Ethereum mining hashrate for all GPU in hashes/s, for example: 25000000.
      • gpu-cash-hashrate - total ZCASH mining hashrate for all GPU in sol/s, for example: 250. Used for the algorithm Equihash (200.9).
      • gpu-redshift - total Redshift rendering benchmark for all GPU in 1/s, for example: 330.

BID order file example (on github):

duration: 8h
price: 2.5 USD/h

# Optional - restricts buying resources only from specified address.
#counterparty: 0x8125721c2413d99a33e351e1f6bb4e56b6b61567

blacklist: 0x8125721c2413d99a33e351e1f6bb4e56b6b61234

# Identity level of the counterparty. Can be "anonymous", "registered", "identified" and "professional".
identity: anonymous

tag: my-app

resources:
  network:
    # Indicates whether overlay networking is required.
    overlay: true
    # Indicates whether outbound connections are required (internet access).
    outbound: true
    # Indicates whether inbound connections are required and public IP should be present on worker.
    incoming: true
  benchmarks:
    # Required RAM size in bytes.
    ram-size: 1000000
    # Required storage size in bytes.
    storage-size: 20000000000
    # Required CPU cores. This only specifies mininum number of CPU threads, not their scheduling.
    # To specify amount of computing power use cpu-sysbench-* parameters
    cpu-cores: 1
    # Minimum computing power of single CPU thread, calculated via sysbench
    # (some abstract value, currently  it is how many times CPU can calculate first 50000 prime numbers in 10 seconds).
    cpu-sysbench-single: 800
    # The same as above, but for all threads, can be less than cpu-sysbench-single when you need less than 1 core.
    cpu-sysbench-multi: 1000
    # Download throughput in bits/s.
    net-download: 12000
    # Upload throughput in bits/s.
    net-upload: 5000
    # Minimum number of GPU.
    gpu-count: 1
    # Minimum memory of single GPU.
    gpu-mem: 4096000000
    # GPU performance - ETH hashrate (hashes/s).
    gpu-eth-hashrate: 15000000

SONM performs decentralized orders matching according to the orders properties.

BID order lifecycle

  1. Customer places a BID order directly on the Market using CLI. Order cann't be changed, only can be cancelled by Customer.
  2. At this moment the amount of SNM tokens for the first period (1 hour for the spot, 24 hour for the forward deals, or if it less - all deal price) are frozen on the Market from the Customer's account.
  3. When the order is placed Customer's Client node automalically monitors the Market searching appropriate ASK orders to match. If the matching ASK is found Worker initiates deal creation.
  4. When the deal is settled, BID order is automatically cancelled by Market smartcontract. Read about deal and billing on the Deal page.
  5. When the deal has finished, Customer may place a BID order using CLI again.

For the supplier the ASK plan and the ASK order lifecycle are described on the ASK plan page.