AldPixto

On the morning of July 9th 2012 I made a few trades in my PFGBest account. I tried to make another trade later in the day and it was rejected with an insufficient margin message. About 24 hours later I understood that my entire margin deposit at PFGBest had effectively vanished from the face of the earth. Maybe I'll see 20% recovery within 3 years time. Maybe more. Maybe less. This past week I opened a new futures account and had to consent to about a dozen agreements, some of which were designed by the NFA, to warn me of the dangers of trading futures and protect the brokerage firm in the event I go bankrupt. No where in this paperwork did I see a disclaimer that the brokerage firm might mishandle my funds or that my margin deposit was at risk for reasons other than my own trading. I enjoy futures but I can't justify the effort unless I trade a large enough account to hold multiple bond, crude, or gold contracts overnight. The stock market has the SIPC and that is where the bulk of my liquid business funds will stay while I see if the CFTC will fix the futures industry.

>>1. Insure all futures deposits up to 25k at 100%, 25k to a maximum at 85% 1. Insure individual futures account deposits up to $250K, a maximum of $1M total for all accounts belong to one SSID/EIN. The program should work like the FDIC and not require depositors to go to court or deal with the delays associated with bankruptcy. [ Canadian customers of MF Global and PFGBest have a similar program and recovered their funds from the Canadian government within three days. ] >>2. Require all posted quotes to be valid for at least 300 MS before being cancelled. 2. Restore the intent of the REG NMS National Best Bid or Offer (NBBO) by forcing some serialization of quotes and cancels from the same customer. What I mean is you have to wait for some exchange computer to see and "stamp" your quote before you can cancel it or submit another quote. The exchange computer implements some fairness round-robin algorithm that makes your quote visible and only then can you stuff the pipe with another order. also... Charge for excess quotes. If the ratio of cancels to quotes exceeds 100:1 charge $0.02/quote for all quotes, else if the ratio of cancels to quotes exceeds 25:1 charge $0.01/quote for the number of quotes over 1000.

If you only have 5K then you just have enough to meet the initial margin requirement for trading 1 contract of the ES ( $4375 ) or YM ( $3125 ), and not enough for the Swiss-Franc 6S ( $6120 ) , Gold (full-size) GC ( $9113 ) , or Crude CL ( $6885 ). A broker can offer you Daytrading margin at somewhere between 1/2 and 1/8th of the exchange required maintenance margin. What are the hours for this Daytrading margin ? For ES is it the global session, i.e. 3:30pm-CT previous-day open to 3:15pm-CT close? I.E. so long as you don't hold when globex is closed you're okay ? OR is Daytrading something you do during pit hours, e.g. 8:30am-CT to 3:15pm-CT ? If you're planning on trading more than 1 contract, then having a time-of-day deadline to liquidate can "squeeze" you in a market liquidation or short-covering rally. The all-or-nothing all-in or all-out mindset for trading a small account gives very little flexibility in regards to scaling in and scaling out of a trade. I've mostly traded CL, ES, ZB and because my account is under $100K I trade QM and QG (the mini crude and mini nat gas) instead of the larger CL and NG contracts because my trading style uses 3 lots (or multiples of 3). If I had a smaller account I might look into other contracts with small margin requirements, such as the M6E micro-EuroFX ( $405 ) , QG ( $776 ), and ICE-DX ( $1320 ). These margin requirements come from the "SPAN" algorithm and can change from time to time when the Exchange recomputes them. The margins for corn, for example, were much less five years ago.

esignal has live tick servers and historical tick servers my live footprint charts will not exactly match the same chart if I request it from a new esignal data manager session and the data comes from a historical server there are also small differences in data between different live tick servers (different users connected to different esignal servers) that can be seen in live chat rooms when a moderator projects their footprint chart and it doesn't exactly match yours - the differences are statistically insignificant, but could in different automatic trading executions if you were triggering on tick or volume bars instead of price bars I know esignal does some quote consolidation (some sort of data reduction via aggregation). My approximate datafeed quote-refresh to trade ratios are much smaller than the nanex numbers. I'm not saying that all is lost, just that you need to accept a certain amount of fuzz with the data you receive.

If there's twenty or more people (* an arbitrary but precise number) who contribute ideas to this thread then I'll try to summarize our observations or gripes with the goal of writing a short list of recommendations for webinar presenters. I think my observations generally apply to several different webinars I've attended this year. I'm not going to single anyone out. My perspective is that of an attendee not a presenter, so I'm not familiar with the options that are available other than pacing a presentation in such a way that most people can keep up, and using more descriptive language than "this one" and "did you see that" when referring to things on a screen.

I thought I'd just let off a little steam and complain about webinar presenters who don't seem to grasp the limitations of online screen sharing technology. In many online seminars the hosts act as though the audience is in the same room as them, looking over their shoulder so to speak. They assume that you see and hear the exact same thing as they do. The reality is that the remote audience gets both their audio and video with some delay. The delay is side-effect of their computer sampling their audio and video (saving some of it in memory in their computer as data), then compressing that data, the uploading that data to the web hosting server. In addition to delay, sometimes video gets thrown away so your computer can catch up. The presenters apparently have no warning this is happening. If you were speaking to someone using the telephone and skype simultaneously the skype conversation would likely have delays compared with the telephone. The telephone companies configure their networks so that voice calls have very low latency (very short delays), but general computer data (i.e. Skype) travels via larger data packets that often have to be buffered and re-sorted before they can be de-compressed and turned back into audio. The result is more delay. Most of the time the audio in webinars is fine because audio data is compact and efficient compared with video. A computer display is a rectangular collection of dots (pixels) where each dot can be one of many colors. A laptop, for example, might have a 1200 x 800 screen , where each dot can theoretically be one of about 4 million colors. Even if we "simplify' this screen so that there are only about 1000 unique colors, it would take around 10Mb of data to accurately reproduce this screen. Few home internet connects can receive 10Mb/second. Engineers have developed algorithms that do a lossy-compression of display data, and that loss is very hard to see. This is what makes it possible to fit a few hours of a high-definition movie on a Blue-Ray or DVD disc. Receiving a compressed movie in realtime requires a lot of bandwidth, more than many DSL connections and even faster than some cable-internet systems can provide, which is why internet movies will "buffer-up" for a little while before they can play back smoothly. This is true even though movies from Netflix, Hulu, etc..., are being streamed from ultra-fast computers with very expensive high-speed internet connections. The webinar hosting companies like Adobe Connect, GoTo meetings, etc.., have computers and internet connections that are just one step below the online movie companies, still very fast, but they do not have unlimited speed. Engineers again write software to compress computer displays, sometimes skipping small screen changes, sometimes reducing the resolution of some parts of a screen while leaving others alone. Instead of transmitting the data for a display several times a second, they might transmit the full screen every second, and then compute and send only updates for the next few display changes before sending the full display again. What ever technology is employed, the end result is that video data has a lossy compression (more fuzzy or less detail than the original). Webinar video will have a delay, and that delay is almost always longer than the audio delay. If a presenter showed three powerpoint slides in rapid succession while saying One, Two, and Three, many remote viewers might still see slide One while hearing the word three. For some viewers their computer might throw away slide Two in an attempt to catch-up with the data being sent.. When you have a poor telephone connection it usually helps to speak slower. The computer equivalent would be sending less data. A powerpoint presentation with simple graphics that is advanced slowly, allowing several seconds for each "page", has a very high probability of being seen correctly by all the remote viewers. Rapidly changing computer data, for example showing a quote page with changing prices or a time and sales window has very high odds of data being either being ignored because its changing too fast, or thrown away because the viewer can't receive the data quickly enough. Besides attempting to transmit rapidly changing displays, presenters also try to share bigger and bigger screens. This is natural because big screens are sexy and can have lots of charts on them. The larger the screen, measured by horizontal x vertical pixels, the more data that needs to be sampled, compressed, and transmitted to your computer. So when a presenter shares their 1920 x 1080 pixel screen, they're not doing anyone a favor because that screen will need much more compression than a smaller screen. Because the viewer's software usually adds things like menu bars, they would need an even higher resolution screen to see the presenters data without their image needing to be compressed (down-sampled) to fit on their screen. I've sat through many a webinar where the presenter was saying something like "see these two things" and they are likely circling some part of their screen with their mouse (or maybe they're totally lost and just pointing on their display with their finger.) I have no idea what they're pointing at because my computer isn't able to show their mouse pointer movements in real time. I've had to listen to crackling audio because a presenter has left their camera on a large rapidly changing tick chart or time and sales window - something they're not speaking about at the time, but their computer and mine are very busy trying to compress their display information and in the process the audio data gets degraded or even partially lost. Okay, thanks for reading my rant. Am I the only person is bugged by webinar presenters who don't know the limitations of the technology they're using?

pH, is there a statistical hypothesis you're trying to prove? A correlation of serial day types? I can download about 5 months of 30-min OHLC bars from eSignal (I think CQG users can get longer history). Do you have IF-THEN-ELSE-like programmable rules that define the classic MP day types? Do you need something more detailed than 30 minute OHLC bars?

You could study SciFi movies to see some designs for your trading setup. For example, in the first Star Wars movie they a large video switcher as the controller for the Death Star weapon. Do a google image search for "Trading Desk". Add points for having something that looks like a Bloomberg console, deduct points for watching CNBC. Leave some statements with multi-million dollar (winning) trades. Tear out a classified page from the back of the Robb Report and circle the next boat or airplane you're going to buy, and keep of photo of you shaking hands with the President (or ex-President) of any big country on your desk. Keep a good sense of humor and good luck with your trading.

I'm familiar with the Market Profile charts from eSignal and Market Delta. The software relies on the user to merge or segment the distributions into meaningful clusters (market units). The software makes no attempt to qualify the input data before displaying a VA. Here's what I mean. Consider [1] a trend day, and [2] a double distribution day. [1] A trend day predominantly has higher highs or lower lows. The computed Mean, VA_H and VA_L would move higher or lower during the day but wouldn't serve as trading reference points they same way they could on a balanced (normal or normal variation) day. On a trend-up day price will likely be above the VA. The ever rising VA_H and VA_L prices on a trend-up day don't help me. I don't look for a VA on a trend day. [2] A typical double distribution day will have an early price cluster, then a breakout from that cluster, and a distinct later price cluster. The computed Mean might be midway between these clusters, perhaps a price with hardly any volume at all. A VA computed from this mean would encompass prices shown to be unpopular. The POC (price with the most TPOs) might be found in the earlier price cluster. When a mid-day event, like releasing FOMC minutes, causes a double distribution, I will split the day into two distributions, they will provide me with more useful reference points. The POC can temporarily be outside the calculated VA. Under such circumstances I think the VA should be disregarded. I would look for VA in a longer time-frame distribution, or shorter under special circumstances.

I'll try to explain some of the terms you'll come across when shopping for a router. cable/dsl ------[MODEM]------[ROUTER]------[sWITCH]------[computer-1] ......................................... [..."..]------[computer-2] ..........................................[..."..]------[computer-3] (A)............(B)..........©...........(D) (A) this should be the slowest link, the wire from your cable or phone/DSL provider. Multiple phone extensions/answering/fax machines can cause interference when DSL is shared with a telephone line. Consider using a POTS SPLITTER and running a dedicated line to your modem. (B) The Modem negotiates the best speed with a corresponding modem at the cable or phone company premises. A modem should provide some diagnostic when its incoming signal quality is degraded (like an Led that blinks yellow instead of solid green if you have a poor signal.) Some modems can connect directly to one computer, but it is more common to connect the modem to a router. In most cases the Route and Switch are in the same box. Sometimes the Modem, Router, and Switch are combined. © The Router provides a network; it routes data your home network to the ISP network. A modern router should provide FIREWALL functionality. A good FIREWALL will say it does SPI (Stateful Packet Inspection.) Routing and Firewall doesn't require much cpu capability, but better routers generally have faster CPUs. The CPU power is needed when the router supports VPN connections. VPNs enable encrypted networks to run on top of regular networks. An employer might provide a router with VPN support to connect to networks behind a corporate firewall. Routers can typically be customized using the web browser of a locally attached computer. (D) The switch supports the connection of multiple devices to a network. Typically the switch is embedded within a router. You'll only know its there because the router has 4,6,or 8 RJ45 jacks (where you plug the wire from your computer.) The words you want to see on a switch are FULL DUPLEX and AUTO SPEED. A slow switch (or a HUB which is even more simple than a switch) only allows one device to "talk" in one direction at one time. A fast switch will allow multiple devices to send data 2-ways and slower devices won't impact the speed of faster devices. There are so many good routers made by Cisco (Linksys), Netgear, D-Link, SonicWall, its hard for me to single one out. I have a Netgear FVS318G router/firewall connected to a DSL modem. From there a long CAT5E ethernet cable runs to my office where I have a Netgear GS108 switch and an EnGenius ECB3500 wireless access point. I recommend staying with the modem that the ISP provides because its unlikely their tech support will be helpful if you're using different hardware.

Vikkktor, try looking for "traders" meetings on meetup.com in your area. Filter out those meetings that are run by trading schools or there may be an inherent bias. You want to find meetings that are run by traders. It could even be a TradeStation or ThinkOrSwim users group, so long as it is run by the users themselves. Then ask the meeting organizers if they can suggest some senior members who might be willing to help you with some questions. Hopefully you'll met several traders and find one or two that you communicate well with. Good Luck

Call it a left-brain, right-brain thing, but I couldn't reconcile what Debbie was saying and what I saw during her free Hotmail webinar on 1-Dec-2009. I didn't see enough of her teaching style to justify the cost/time of taking her course.

I've put several years of futures price data into MySQL tables. My thoughts are: 1 - Timezones are important 1a - The database should self-identify what timezone data is being stored in, e.g. some integer offset relative to UTZ (i.e. keep database in EST, CST, whatever makes sense to you) 1b - Data loading applications need to know what timezone the source data is in so they can normalize to the target database (becomes important when people in different timezones can contribute data) 1c - User Applications (e.g. charts) should be able to convert database times into end-user times 2 - Even if you're only computing or plotting "floor" session data, it is useful to have 24-hour data (e.g. globex) so that overnight high low prices are known 3 - Market Profile charts 3a - the maximum time quanta is 30 minute bars, the "current" bar can be updated with greater frequency (e.g. every 30 seconds) for semi-realtime charts 3b - Volume-at-Price data is necessary for Market Profile but it will force you to compromise the minimum price-delta (e.g. $1 for $BRK.B , $0.01 for $GLD) 3c - separate tables for OHLC (key: YYMMDD,HHMM) and Volume-at-Price (key: YYMMDD,HHMM,Price) help speed charting for MP and non-MP charts 4 - Store dates and prices as integer values 4a - need date methods to compute yymmdd+date_offset and (yymmdd+-yymmdd) as date offset (my database is in yymmdd and I will have to convert to yyyymmdd by next year) 4b - convert fractional prices (ags, bonds) to integers so that ranges can be easily computed, e.g. multiply Ag prices by 25 and 30-Year bonds by 15625 to eliminate the fractional portion of the price 5 - DBA stuff - data sources are imperfect and I have to reload data to remove bad ticks or fill-in missing times more often than I'd like. the real problem is finding bad data or missing ticks before the tick data goes offline (DTN tick data only goes back 8 days, eSignal tick data goes back 10 days)

can we define our goals and resources a little more: what various platforms would you consider: trading platform: your program runs inside a trader application: - CQG formula - Tradestation easylanguage - Ninja Trader - Neoticker - eSignal other platforms: - Matlab - R - web server/web browser native platform: - C# - C++ - VB - Java - Perl, PHP, Python Writing a program (aka script) that runs within a trader application allow you to focus entirely on your algorithms because the programming for datafeeds and visualization has already been solved. The platform philosophy (single symbol, action occurs after a "bar" has closed) may not allow you to express your own ideas as you originally envision them. Using a non-trader application you will need to consider your datafeed requirements, especially if you want realtime data. Maybe this is already solved with CQG-Matlab? Native platform means running directly on your computer operating system, e.g. a program that runs under Windows, MacOS, or *Nix. In a pure computer-science definition, native means your program is translated to machine code that runs directly on hardware. In fact, this only occurs with C++. Writing an interactive realtime application, will require learning a great deal about COM or .NET for datafeeds and thinking about event driven (rather than linear) programming. Unless you intended to become a hobbyist or professional programmer I would avoid this route. Programs which read and write files and do not require a GUI are relatively easy in any of the programming languages. I would favor an interpreted language like Perl, PHP, or Python (I prefer PHP since I also use it for web programming.)

Interbank forex has no hours and no centralized reporting of volume. [1] what session time What hours is the market most active? I'd want to look at a histogram of trade activity vs time-of-day and pick the busiest times, or conversely find the quietest time as the closed-time. Or I'd use the globex hours for the CME exchange-based currency futures. [2] what volume If my data provider reported trades but no volume, then I'd use tick volume as a proxy for trade volume. If I only had price quotes but no idea where trades were executed, then I'm severely limited in understanding the market from a value perspective, I wouldn't know the POC or the volume weighted mean.

When I am thinking "Market Profile" then I use the floor trading hours. Things like Initial Balance and Settlement make sense when applied to a Market Place driven market (markets that open and close). I do most of my MP thinking looking at end of day charts for important price levels for the next days trading session. While trading I use Volume@Price (Market Delta Footprint charts) set to Globex hours, but I always keep in mind what hours a given commodity has the most volume. The most volume almost always coincides with corresponding floor hours. I have observed some markets (e.g. ES, QM, and YG) can get significant volume an hour or two before the floor opens when there is significant news.

Can you say more about your requirements? Lets say you have a table with rows of volume@price. What is your requirement for time resolution on the table columns? - daily columns - 30 minute columns - 5 minute columns Have you already thought out the SQL schema for your database? Can you share those ideas? If the SQL tables only updates once a minute, would that latency be too long for your signals? If you only want Volume@Price to calculate VWAP, could you eliminate that requirement if some data source calculated VWAP for you? ...... Some brokers can provide "free" data using their API if you have a funded active account. example: IB (Interactive Brokers) Is there some way to exchange data between TradeStation's EZlanguage and another program? I don't know. You can buy realtime datafeeds from eSignal or DTN, then use a program like QCollector to do timed updates of CSV datafiles. You can write a program to poll these datafiles and update a database (like mySQL or PostgreSQL.) Yahoo Finance and even some exchange web sites (CME) have end of day data available for free.

Think - What is the intent of the value area? The value area is the range of prices where the majority (70%, 68.2%...) of trades occur. So - Given a dataset with trades (date/time, price, lot-size) I can easily compute a POC-TPO style value area or a Volume-Weighted value area, right? Yes, the numbers can be computed, but they lack meaning when the dataset contains multiple distributions or even a single distribution that lacks rotation. What? What? What? Consider multiple distributions, the most simple example is a day with congestion and price rotation around some set of prices, then a midday fast far away from the earlier prices followed by congestion and price rotation around the new price area. A volume profile would show two distribution peaks with little volume between. A market profile would similarly show two distributions with single prints between them. The computed value might be between these two distributions. The value area POC or Mean, value high and value low reference prices are meaningless. Consider a single distribution from a day in which price had micro-rotations (e.g. up a few ticks, down a few ticks) during the entire day, however the majority of 30-minute periods price made higher highs, higher closes, and higher lows. This is a trend day. Each time we compute our MP reference prices they are moving higher (that is significant) but as far as producing levels from which to trade the computed value area is of no use. Think - What kind of day has a value area? The volume or TPO distribution should have a central high area and low edges. We could have an idealized bell curve, but an asymmetric blob is more likely. The high volume area can be near the top, middle, or low. There should be some price rotation occurring around the high volume areas. As a general guideline, I want the value area for the ES,ZB,and ZN to have prices with five or more TPOs. I adjust the threshold for other markets, e.g. four or more TPOs is sufficient for ags (corn, soybeans, wheat). Some authors use the term balance or bracketing to mean a market with price rotation. Conclusion - Keep in mind that just because we can compute a value area, that doesn't mean we have useful numbers to trade with. Markets that are consolidating or congesting have value areas. Trending markets do not.

I save tick data from eSignal using QCollector. I have it configured to save separate ascii files for each futures contract I follow, e.g. YGZ8_0.csv , and when those files approach 2Gb I rename to YGZ8_yymmdd.csv (where yymmdd is the last day of full data) and then start collecting a new YGZ8_0.csv file. I configured the file content as: yymmdd,hhmmss,<trade_price>,<trade_volume>,,,, yymmdd,hhmmss,,,<bid>,<bid_size>,<ask>,<ask_size> the contents are CSV as either trades or quotes with best bid/ask When a contract is a back month I compress it with gzip, so for example ESH8_0.csv becomes ESH8_0.csv.gz . Gzip seems to achieve about an 8:1 compression on these ascii files. My applications recognize the .gz file extension and either decompress the files when needed or else directly read the .gz files (e.g. java GZIPInputStream).